[llvm-dev] RFC: Element-atomic memory intrinsics

[Daniel Neilson via llvm-dev]

Hi Vedant,
 Responses inline...

On May 8, 2017, at 1:22 PM, Vedant Kumar <vsk at apple.com<mailto:vsk at apple.com>> wrote:


On May 8, 2017, at 10:49 AM, Sanjoy Das <sanjoy at playingwithpointers.com<mailto:sanjoy at playingwithpointers.com>> wrote:

Hi Daniel,

[+CC Mehdi, Vedant for the auto upgrade issue]

On Mon, May 8, 2017 at 7:54 AM, Daniel Neilson via llvm-dev
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
**Method**

Clearly we are going to have to teach LLVM about unordered memory
intrinsics. There are, as I can see it, a couple of ways to accomplish this.
I’d like your opinions on which are preferable, or if you can think of any
other options. In no particular order…

Option 1)
Introduce a new unordered/element-atomic version of each of the memory
intrinsics.
Ex: @llvm.memcpy_element_atomic — work was already started to introduce
this one in D27133, but could be backed out and restarted.

I'm curious about this -- do you know why the decision was made in D27133 to go with a new intrinsic, instead of extending the existing one? Would the same rationale apply here?

The rationale as I understand it basically boils down to minimizing risk — make the changes with the introduction of a new intrinsic that’ll be invisible in practice to anyone except Java, see how that looks/feels, and then extend the existing one (& remove the added one) once it looks like it’ll work. I have no problem with continuing that line, but I do prefer to move away from the separate intrinsic after the thing has been proven out.


Cons:
* Breaks backward compatibility of the IR — is there a mechanism for
migrating old IR into a new IR version when loading the IR into LLVM?

I think the migration here will be fairly straightforward -- you can
just auto-upgrade old calls to memcpy to pass in 0 for the isordered
argument.  But I've CC'd Mehdi and Vedant to help shed some light on
this.

LLVM has one test which for backwards-compatibility with old versions of the memcpy intrinsic, which provides limited coverage (standardCIntrinsic.3.2.ll).

Whichever option you choose, it would be helpful to add uses of the new intrinsic to test/Bitcode/compatibility.ll. If you choose Option 2, it would also help to copy these uses into the 4.0 bitcode compatibility test (with "is_unordered" dropped), and to re-generate the bitcode for the test. I can help out with this if you'd like.


Will do, and I’ll definitely reach out for assistance with the bitcode compatibility test when the time arrives. Thanks!

-Daniel

---
Daniel Neilson, Ph.D.
Azul Systems


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170508/bd625d40/attachment.html>