My colleague Jonathan Swinney helped reduce a testcase:

Ping patch.

The binary was created with clang-14 from Ubuntu 20.04.

Updated patch to pass clang-format check.

The updated patch checks the equality of SegInfo.FileOffset and FileOffset when both are alignDown by SegInfo.Alignment:

Updated patch to mark the code of functions as executable on a new mapping symbol.

The following patch fixes the issue by checking whether the Address is at the beginning of the new symbol.
If the Address is at the beginning of a new symbol, the decode type should not inherit the decode type of the previous symbol:
it should revert back to the default disassembly mode.

Thanks @yota9 for the hints.
The code preceding the function is indeed marked with $d:

I let delta reduce the yaml representation of the binary, however it did not go very far over night...
Maybe delta could work on smaller inputs (this current one is way too large: 4Gb.)

Yes, I will provide a testcase in assembly.

I will reduce a yaml object testcase for this fail.
Do you have a specialized reducer for yaml object files?
Otherwise I'm going to use a line by line reducer: https://github.com/dsw/delta

Instead of removing the assert, the patch avoids collecting CFI info on functions without instructions.

Moved tests to X86/

Reduced yaml input file.
Tested with and without the patch for the pattern.

Thanks Amir for the tip, configuring with -DLLVM_ENABLE_PROJECTS="clang;bolt;lld" enabled check-bolt target.
Thanks yota9 for pointing out the format for the test "pre-built binary in yaml format", I adapted my test following one of your previous tests.

Added testcase that passes with the patch.
Tested on arm64-linux (Graviton3 Neoverse-V1.)

Recommended check-bolt fails with:

$ make check-bolt
make: *** No rule to make target 'check-bolt'.  Stop.

I added a testcase, however I was not able to check if the test catches the issue.

The patch looks good to me.
Applying this patch solves this issue:
https://github.com/llvm/llvm-project/issues/55199
which is a reduced test from Rust generated code.

Ping patch.

Ping patch.
Could one of the arm64 maintainers approve this patch and commit?
Thank you.

The change looks good to me.
Could one of the arm64 maintainers also approve this patch? Thanks!

Hi Salvatore,
the patch looks good to me.
As you suggested to me, we should also remove this part let Predicates = [HasPerfMon] in.

Hi Pavel,

Looks good to me.

Thanks Renato. Short and long term plans look good to me.

In D102861#2782735, @rengolin wrote:

I agree. I'm just trying to avoid running tests that don't do anything. If we're not going to have fp-contract on Polybench, then we shouldn't be running it twice, just roll back those changes and suppress fp-contract on them.

To be clear, I'm happy with the flags being there, I'm just not happy with blindly applying them without disabling the second Polybench run.

In D102861#2782166, @mibintc wrote:

The clang patch was stalled months ago due to this test-suite, but many floating point experts opined that the clang change is deisreable.

I tested this change on Graviton2 aarch64-linux with clang -moutline-atomics.
clang was configured with compiler-rt:

cmake -v -G Ninja \
  -DCLANG_DEFAULT_RTLIB:STRING=compiler-rt \
  -DLLVM_ENABLE_PROJECTS:STRING="clang;compiler-rt;libunwind" \
  -DCLANG_DEFAULT_UNWINDLIB:STRING=libunwind \
  -DCMAKE_BUILD_TYPE:STRING=Release \
  -DCMAKE_INSTALL_PREFIX:PATH=/home/ubuntu/llvm/usr/ \
  ../llvm

I tested this change on Graviton2 aarch64-linux by building https://github.com/xianyi/OpenBLAS with clang -O3 -moutline-atomics and make test: all tests pass with and without outline-atomics.
Clang was configured to use libgcc.

This cleanup looks good to me.

Looks good to me. Thanks!

Ping.

I looked at both the SLP and loop vectorizer and I think this is more work than I can do right now.

In D67645#1674197, @az wrote:

There are few things missing in current work such as indexed dot product or what they call s/udot (vector, by element) in the ARM document (no need to do it now but a comment about that would help).

In D67645#1673951, @SjoerdMeijer wrote:

to do the heavy lifting, this is probably a task for the loop vectorizer.

To catch more dot product cases, we need to fix the passes above instruction selection.

In D67645#1673114, @SjoerdMeijer wrote:

• was just curious about the AddedComplexity = 30

In D67645#1672161, @SjoerdMeijer wrote:

I've got a cheeky request, and I appreciate that should go in a separate patch, but while you're at at it would you mind repeating this exercise for the ARM backend and AArch32?

The new patch does not use the first argument of the dot product instruction: we now set it to zero.
Patch tested on x86_64-apple-darwin with make check-all.

Excellent!
Thanks for catching those patterns.
Please commit.

I still see a link error on aarch64-linux on master:

/usr/bin/ld: tools/clang/lib/AST/CMakeFiles/obj.clangAST.dir/AttrImpl.cpp.o: in function `clang::AttributeCommonInfo::getAttributeSpellingListIndex() const':
/home/ubuntu/llvm-project/llvm/tools/clang/include/clang/Basic/AttributeCommonInfo.h:166: undefined reference to `clang::AttributeCommonInfo::calculateAttributeSpellingListIndex() const'
collect2: error: ld returned 1 exit status

I reverted locally this patch and it finishes building.

In D67497#1668236, @SjoerdMeijer wrote:

The patch looks okay to me, but I am still curious what happens with i16. The lowering to umov w8, v0.h[1] in build-vector-extract.ll is probably the interesting one. This is probably covered by rule:

Looks good to me, please apply.

Updated patch by removing the patterns that generate i16. Patch passes make check-all on aarch64-linux.

The tablegen error only happens on the i16 patterns:

def : Pat<(i16 (extractelt (v8i16 V128:$V), (i64 0))), (EXTRACT_SUBREG V128:$V, hsub)>;
def : Pat<(i16 (extractelt (v4i16 V64:$V), (i64 0))), (EXTRACT_SUBREG V64:$V, hsub)>;

If I remove these two patterns, make check-all passes.

In D67497#1667851, @evandro wrote:

Is there a test case that checks that this change does not break what the code in AArch64DAGToDAGISel::Select() was meant to handle?

Never mind. You cannot do the other ones as it would call Match too many times and would not follow the semantics of the original code.

Almost LGTM.

I like the patch. Thanks!

Updated patch to current llvm trunk.

Ping patch.
The last version of the patch addresses all the comments from reviews.
Ok to commit?

For some reason asan/tests/asan_noinst_test.cc is not compiled on make check-asan and that has exposed a compile error that was not triggered by the other tests:

sanitizer_double_allocator.h:30:11: error: use of non-static data member 'use_first_' of 'DoubleAllocator' from nested type 'DoubleAllocatorCache'
      if (use_first_)
          ^~~~~~~~~~

The updated patch fixes this by accessing the non-static field of the enclosing class through a this pointer to one of the instances:

-      if (use_first_)
+      if (this->use_first_)

The updated patch passes make check-lsan check-asan and is still under test for check-all on aarch64-linux.

The updated patch I will post is addressing all the review comments.

Addressed comments from @vitalybuka: factored up the 3 versions and added more tests.
Passes with no new fails ninja check-all on an AArch64 Graviton A1 instance.

Fix the x86_64 overflow warning with 1ULL << 48.

Updated patch fixes ASan.

I have verified that the updated patch compiles and it reduces the execution time of leak sanitized trivial example.

This patch reduces the number of #ifdefs as suggested by Kostya, and speeds up both the leak and address sanitizers on aarch64.
Passes check-all on x86_64-linux and aarch64-linux is still under test.
Worked with Brian Rzycki @brzycki.

Also, this is changing only the standalone lsan, not lsan used as part of asan. Right?
standalone lsan is not widely used, AFAICT.

Address review comments from Kostya: move AArch64 lsan allocator to a separate file to avoid #ifdefs.

Ok, I will prepare an updated patch.
Thanks Brian and Kostya for your reviews.

Looks good to me.

Rebased patch on today's trunk.