No comment, thanks for the patch!

Extra round of tests on my side: current version leads to 550 instruction moved when compiling cpython with -ftrivial-auto-var-init=pattern. @nikic I think the patch is ready for you to look at it again :-)

Update test case according to @nikic review.

Fix variable naming.

Take into account all @nikic comments.

@cjdb : should be good now :-)

Fix ADL

Fix test

Take review into account.

Still get a

+ constexpr version
+ check for ub in bitwise shift.

First time contribution to libc++, I apologize in advance if the style / conformance is not correct.

@nikic : I've not addressed your inline comments yet, but I've improved the approach through alias analysis, this indeed looks better now, at least to me. What do you think?

Use Alias Analysis to filter-out non clobbering memory accesses, as suggested by @nikic . Also added a test case (clobber.ll) to ensure this works as expected.

In D137707#4164689, @nikic wrote:

High level notes:

• I'm not sure I fully understand the motivation for using MemorySSA here. Unless I'm missing something, It seems like when it comes to optimizing allocas, it would be sufficient to look at non-transparent users of the alloca (by which I mean, in first approximation, look through bitcast, gep, count everything else). The review mentions fences, but wouldn't these be covered as long as you consider pointer captures as "uses"?

The cleanup looks good to me, thanks! Out of curiosity, did just stumble on this, or did an automatic tool gave you an hint?

LGTM (I assume that most of the time, we're just copying pointers and it's fine either way).

I'd like to move forward with this, and try to implement a more general approach that considers any instruction, and not only the instruction generated for auto init. But I need to unlock that review first :-)

No need to check if getMemoryInst returns nullptr or not.

@thieta ACK once you fix the issue spotted by@jlpeyton.

Fix MemoryPhi handling

Superseded by https://reviews.llvm.org/D144029

Thanks for providing a much more satisfying approach than the one I proposed in https://reviews.llvm.org/D144020 !

Some extra call to list are correct wrt py2/py3 compat but are actually not needed, let's not introduce them at all.

@efriedma : gentle ping :-) Any thoughts on this version, now based on MemorySSA?

Address @tbader's comment

remove mutable qualifier

@efriedma : any comment / opinion on this now that it's based on MemorySSA?

Take into account @nickdesaulniers review.

Gentle ping :-)

looks good to me!

Do you intend to (optionnaly) provide XXH3 as described in https://github.com/Cyan4973/xxHash ?

Can you take a shot against https://llvm-compile-time-tracker.com/ so that we get an hint of the practical speedup?

In D142606#4082753, @tstellar wrote:

Does this mean that clang will no longer search for the ROCM and CUDA library paths for every C compile?

In D142464#4081513, @mehdi_amini wrote:

How did you find this? Just random audit of the code?

I did a quick check and it was indeed tuned

Address review + rebase patch

This got fixed in d1f313e73a1b33d662dbab54be76720b9c875645.

Do not enfore StringLiteral parameter. This is too invasive on the code base.

In D142181#4070881, @nikic wrote:

In D142181#4070868, @serge-sans-paille wrote:

@nikic : I thought I fixed that with e8a163dc03e6913360beb305620104ba129c081c ... is it included in your build?

Oh yeah, I missed that fix. Sorry for the noise.

Plausibly caused by this change -- I'm thinking that MaximumDistance is initialized to UINT_MAX - 1, but then we cast that to a signed integer and compare that, so it wraps to a large negative number.

@nikic : I thought I fixed that with e8a163dc03e6913360beb305620104ba129c081c ... is it included in your build?

Fix build + make StringLiteral initialization constexpr.

Thanks @nikic for the review. Remarks taken into account.

Fix and document alignment requirements

remove FIXME

Add alignment requirements

LGTM

nits + rebased on main

In D140800#4043723, @nikic wrote:

Just to check, this isn't going to cause some warning spew about all those OptTable implementations being non-final?

Nits + rebase on main branch