This was discussed in llvm-dev mailing list, and originally we had a change that was closer to what GCC was reporting however there was no consensus on what was needed. The purpose of this change is to bring parity in terms of available options with GCC. @lebedev.ri could you chime in on what your specific use for this flag is?

@MaskRay Yes this would unblock applications. Regarding your concern, the information from this implementation as well as GCC's should be used conservatively as both are approximate.

ping

ping @Quuxplusone this is being used as a diagnostic flag that aliases "-Wframe-larger-than", I think if we want to add more user-facing documentation to clarify things we should revisit what the "-Wframe-larger-than=" tracks as well. Currently there isn't too much info on that flag either.

@bruno all tests are passing, could you take another look when you have a chance?

ping

Updated Release Notes and rebased

Updated test and aligned negative flag with gcc

Updated test

rebase

Moving forward with simpler approach here:
https://reviews.llvm.org/D102782

Moving forward with simpler approach here:
https://reviews.llvm.org/D102782

Thanks for reviewing @bruno doesn't look like the failure is related to my change:
https://buildkite.com/llvm-project/premerge-checks/builds/39905#5f70c261-ae54-451b-b771-7012bcee7387
"No space left on device"

Localized changes to Options.td, needed to explicitly add negative
flag for -Wframe-larger-than

Another approach is explored here:
https://reviews.llvm.org/D101964

Another approach is explored here:
https://reviews.llvm.org/D101965

minor fixes and merged https://reviews.llvm.org/D100499

Merging with https://reviews.llvm.org/D100772

Here's the fix for enabling these on ARM:
https://reviews.llvm.org/D100772

only the pol128 intrinsic is incompatible with ARM, the rest should be supported.

Thanks for looking into this @DavidSpickett ! What you found makes sense. I'll update this patch to remove only the poly128 vadd from the mapping. I'll also add another patch that will correctly enable the remaining vadd intrinsics for ARM.

As you mentioned, I thought it was only supported due to CheckFPAdvSIMDEnabled64. If the header is also guarding for AArch64 does that not support the idea that it is AArch64 specific?

Thank you for reviewing this @DavidSpickett ! If you get a chance could you commit this for me? I do not have commit access yet.

rebased on main

Windows builds were failing due to missing builtins in Intrinsics map

Minor corrections and removed unused code, also added complete testing

Removed extra whitespace

removed unnecessary flag in test and changed commit message.

rebased due to merge issues

This is the final of three patches to address the following:
https://bugs.llvm.org/show_bug.cgi?id=47828

alphabetized check in NeonEmitter

@labrinea could you commit this when you have some time please?

This is the second of three patches to address the following:
https://bugs.llvm.org/show_bug.cgi?id=47828

Updated test name and checks performed

@t.p.northover Could you take a look before I ask for this to be merged?

Corrected register ordering for sm4e and removed redundant argument in sm3ss1 test

Thank you for taking a look at this @labrinea !

This is the first in a series of patches that will address the following:
https://bugs.llvm.org/show_bug.cgi?id=47828

I am trying to enable LoopDistribute, to observe the 43% uplift on hmmer2006, however "flto -mllvm -enable-loop-distribute" does not seem to improve performance. Could you share what other flags you used?

Incomplete patch, accidentally pushed

Yes! If you could commit it for me that would be great! Thanks

Ran update_llc_test_checks.py and added missing isVector check

Added comment for readability

updated usage of param

Changed the name or the param and added appropriate formatting

My apologies @Florian! Thank you @fhahn!

@Florian since we've given it a couple days, would it be ok to make the commit now?

@fhahn yes if you could please commit this for me, it would be much appreciated. I am new to LLVM so I do not have commit rights yet! Could you also do the same for the other patch that was split, D82342

Abandoning as I have split in the following:
https://reviews.llvm.org/D82342
https://reviews.llvm.org/D82343

I've split the changes up:
https://reviews.llvm.org/D82342
https://reviews.llvm.org/D82343

I can definitely split this into two different patches

Ran clang-format to update the patch