Yes, losing a bit of history is unfortunate. However, it will make it easier in the future to keep these bindings machine-formatted.

Ok, based on the above comments I believe that this is a bug in LLVM and not a missing feature in compiler-rt. LLVM should generate __atomic_* calls instead of __sync_ calls and it shouldn't generate those for Cortex-M3 and up when doing 32-bit atomics because it should be able to emit such instructions inline.

Phabricator says:

Merged in r362893.

Merged in r362890.

Merged.

• update to stripPointerCastsSameRepresentation
• move a single line of code (NFC)

I think I have addressed all review comments (except for stripPointerCasts which is waiting on D61607 and should hopefully land soon).

• use Value::getPointerDereferenceableBytes instead of checking for the specific attribute dereferenceable_or_null.
• Only apply this optimization when null pointers are not dereferenceable ("null-pointer-is-valid") and add an associated test.

Yes I know it can change the bit pattern. And if it is only about the bit pattern, the name is fine. However, it seems to me that the only difference between stripPointerCastsSameBitPattern and stripPointerCasts is the AS, which may or may not be relevant to the bit pattern. This is confusing: it isn't clear to me from the name stripPointerCastsSameBitPattern whether it may strip any addrspacecast that has the same bit pattern.

I've updated the code, but there are a few things I'm not so sure about:

• replace some types with auto
• update comment for getelementptr inbounds

To me (someone from outside LLVM), the "keep bit pattern" argument looks confusing. Pointer casts do not necessarily change the bit pattern? In fact, it seems to me that most pointer casts preserve the bit pattern but change the meaning of the pointer (example: address space 1 on AVR which points into flash instead of RAM - no bits are changed with an addrspacecast). Names like stripTrivialPointerCasts and stripAddressSpaceAndPointerCasts look much more obvious to me. Or did I miss the real intent of the change here?
In other words, I would suggest renaming stripPointerCastsSameBitPattern to stripTrivialPointerCasts.

Thank you, so I guess this is now ready to land?

• updated to allow bitcasts
• include bitcasts in tests
• other small improvements to the test

• now _really_ update the URL

• updated the URL to the GCC docs

• fixed the bug in SYNC_OP_8

• use the ldrex/strex implementation on Cortex-M3 and up for SYNC_OP_4
• fixed a bug in SYNC_OP_4 for the sub instruction (a bug remains in SYNC_OP_8, will fix soon)

No there isn't any reason to avoid ldrex/strex on M-class. It is the recommended way of implementing these functions on all architectures that support them.

If someone could suggest a good way to test this, that would be great. At the moment it has been tested by compiling for armv6m, armv7m, and armv7em and confirming that the add operations appear to work.

Update CaptureTracking to be more conservative and add FunctionAttrs tests.

Great!
Can someone merge this commit? I do not have commit access.

wrong patch

Ping?
I don't have commit access.

Oh, I see. Thank you for explaining the actual behavior of getelementptr.

Some more background:

Can you (or someone else) merge this change? I do not have commit access. That would allow a request for inclusion in LLVM 8 (I hope).

Can someone merge this patch? I don't have commit access.

Can someone commit this change? I don't have commit access.

Ping?

Moved LLVMPassManagerBuilderAddCoroutinePassesToExtensionPoints to lib/Transforms/Coroutines/Coroutines.cpp.
This also required moving of wrap/unwrap functions for the PassManagerBuilder, as they were defined in lib/Transforms/IPO/PassManagerBuilder.cpp instead of in a header file. I think that's the reason I added them originally to PassManagerBuilder.cpp instead of to Coroutines.cpp.

Can someone merge this patch?

Ok, will update the patch.

Can someone merge this patch? I don't have commit access.

ping?

Can someone merge this patch? I don't have commit access.
Also, this patch needs merging too: https://reviews.llvm.org/D47684

@whitequark ping?

Can someone merge this patch? I don't have commit access.

Can someone merge this patch? I don't have commit access.

@whitequark ping?

I have another Go API addition which I'd like to see included, and I'm not sure who I should add as reviewer for these patches.

Thank you for reviewing! Is there anything I need to do now to get this merged? I'm new to LLVM development.