In D146804#4631923, @Mordante wrote:

Friendly ping? We'll be moving to GitHub soon can you update the patch if still interested into getting this in libc++?

@nikic @mohd-akram Thank you for the review

Change according to clang-format

Rebased

In D155168#4496699, @nikic wrote:

Tests for this feature also cannot be easily added: https://reviews.llvm.org/D134134#3801747

You should be able to test that InstCombine does not perform the strrchr -> memrchr fold if a macos triple is given.

Fix typo (memchr -> memrchr)

Update patch

As far as I know, all powerpc(64)?(le)?-linux-gnu triples are reported as unsupported except for powerpc64le-..., so PowerPC support seems to be not unconditional.

Address review comments

So what are next steps? Are we going for implementation of DW_AT_no_unique_address (which is going to be a non-standard extension) ?
@dblaikie @aprantl @Michael137

In D147776#4286705, @courbet wrote:

I wanted gchatelet@ to have a look at this, because he wrote the Instruction/Operand code. In particular, I'm wondering why we're not using the info on the actual Operand value rather than relying on the MCOperandInfo for the operand. Specifically, we do know that this is a register since we return true for isReg, so we could just bake this knowledge into getExplicitOperandInfo in a target-independant way.

That being said, I don't know how the AArch64 backend is design, but it feels weird that the target info for that opearnd is OPERAND_UNKNOWN if we know that it's a register.

Address review comment

In D147699#4276622, @kpdev42 wrote:

In D147699#4274228, @tstellar wrote:

Ping on this, can we revert or fix this? I don't think running the aarch64 tests on a big-endian system is really supported. This is the same kind of crash that prompted by to write D145763.

Sure, will try to fix it

Sorry for delay, this patch https://reviews.llvm.org/D148921 should fix the tests on s390x and make it possible to run tests that not involve code execution on any platform. The issue seems to be because llvm-exegesis was initially intended to only generate code for host CPU, so even after --mtriple option was introduced it used MCJIT for fetching assembled_snippet for historical reasons.

ping
@courbet could you please take a look?

@jingham could you please take a look?

ping

In D147699#4274228, @tstellar wrote:

Ping on this, can we revert or fix this? I don't think running the aarch64 tests on a big-endian system is really supported. This is the same kind of crash that prompted by to write D145763.

Reworked the patch. Now it should not increase the size of unrelated
llvm tools and clang. Most of the changes to TableGen emitter are
factored out into a separate patch https://reviews.llvm.org/D148516

ping

@jrtc27 Please take a look

Address review comment

Address review comments

ping

ping

Thanks for pointing out the bug @Michael137 . It seems that clang assigns arbitrary offsets for non_unique_address so analyzing them brings me nowhere. In this patch I tried assigning no_unique_address to every empty structure and this fixed issue you found, making the code changes much smaller and simpler. The lldb test suite pass for me as well

Address review comments

@aidengrossman thank you. LGTM (only need to fix typo)

Address review comments

In D146303#4251056, @courbet wrote:

Thanks for the data. Can you get someone to approve that the size change is OK ? Otherwise LGTM for the exegesis part.

Rebase patch

Rebase patch

ping

ping

Address review comments

In D146804#4219175, @philnik wrote:

As usual: Do you plan to get official support for OpenHarmony in libc++? If that's the case, please take a look at https://libcxx.llvm.org/AddingNewCIJobs.html#addingnewcijobs.

In D146804#4219942, @Mordante wrote:

Can you update the commit message to explain what OHOS is and provide a link to its homepage. That would be nice to have as a future reference.

Address review comments

@jrtc27 Patch was updated, please take a look

Updated after D143708 landed

Fix test

ping

In D146303#4223120, @courbet wrote:

In principle I like that, however this has implications on the size of the various llvm binaries. Can you please measure the increase in binary size for e.g. clang ?

Updated after D146302 and rebased