Rebase.

Rebase and add adjust MVE masked load handling. Also make use of update_llc_checks - I tried it again and this time it did use a single CHECK when both little-endian and big-endian code generation are the same, so it looks like I was using it wrong somehow before (though I don't know in what way).

Do this in ARMTargetLowering::PerformDAGCombine

Release note added: https://reviews.llvm.org/rG0cff81cff05d

LGTM.

In D76514#1937042, @dmgreen wrote:

Would it make sense to do this as a DAG fold? That way we would get MVE for free too.

A few small changes:

• Don't start C++11 spelling with :: (changes to name normalisation to allow this are in D76704)
• Don't check that the Decl is null in diagAppertainsToDecl
• Return AttributeNotApplied on errors in handleDeclAttribute

Apply clang-format changes.

Use an enum for the return value.

Updated to match the changes to D31342

Adjust GEP handling to reduce AllocSize by Offset instead of using the result size.

Use the allocation size instead of the allocation type.

Adjusted to avoid looking through pointer types by passing around the allocated type and checking it against the size of memory accesses. Also correctly handle GEPs where the addressed member is partially outside of the allocated object.

Added bitcast handling.

Removed loop tests.

In D75695#1912905, @probinson wrote:

Changes look good, but there's still the question about whether you really need the loop tests.

Update based on review comments.

Use getTypeAllocSize, apply clang-format.

Abandoning this old patch (the underlying problem was solved by https://reviews.llvm.org/rL348496 which made GVN PRE not introduce the problematic phis in the first place).

Abandoning this old patch that I have no intention of doing any further work on.

I've been looking into attribute merging, and as far as I can tell there's two things going on:

• In SemaDeclAttr.cpp, the various handleXyzAttr functions may call mergeXyzAttr to handle clashes with other attributes within the same declaration.
• In SemaDecl.cpp, several functions call mergeDeclAttributes, which calls mergeXyzAttr, to handle clashes with attributes in a previous declaration of the same thing.

Rebased and added link in documentation.

Update based on review comments.

Doing a clean checkout and build on Linux using the following commands I get the same test error:

Running that command (with this patch applied to trunk revision 56ac9d30d35632969baa39829ebc8465ed5937ef) I get

Note: Google Test filter = VFSFromYAMLTest.MappedFiles
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from VFSFromYAMLTest
[ RUN      ] VFSFromYAMLTest.MappedFiles
C:\Users\johbra01\llvm-project\llvm\unittests\Support\VirtualFileSystemTest.cpp(1411): error: Value of: S.getError()
  Actual: true
Expected: false
[  FAILED  ] VFSFromYAMLTest.MappedFiles (30 ms)
[----------] 1 test from VFSFromYAMLTest (94 ms total)

Update based on review comments.

Update based on review comments.

This has been rewritten so that the registry is only used for attributes added by plugins, and everything else continues as before. This also removes the strange dependency I'd previously introduced, where Attributes.cpp (in libclangBasic.so) declared and used the registry but ParsedAttr.cpp (in libclangSema.so) populated it - now the registry is declared and used solely within ParsedAttr.cpp.

This causes a lot of test failures in llvm/unittests/Support/VirtualFileSystemTest.cpp. A lot of them use //root as a root directory, and e.g. looking at the MappedFiles test what's happening is:

• //root/foo/bar/a is added to the DummyFileSystem
• getFromYAMLString used on a YAML string that maps //root/file1 to //root/foo/bar/a
• The //root/foo/bar/a is canonicalized to /root/foo/bar/a
• O->status("//root/file1") matches the //root/file1 in the YAML, but the subsequent lookup tries to find /root/foo/bar/a which doesn't match the //root/foo/bar/a that was added to the DummyFileSystem so we get a "file not found" error

In D73201#1878706, @hans wrote:

A user reported running into asserts when compiling musl for aarch64 with -frounding-math.
It appears to be fixed (well, at least it doesn't assert..) by this patch. Should it be cherry-picked to the 10.x branch?

LGTM, though with a suggestion for adjusting a comment to be clearer.

It looks like the change that introduced isInvariantLoad was reverted in commit 446acafb82b5c116b6c94c11d4ac4db7641fa58d, so it's a bit hard to review this with current trunk. Is there any problem with memory dependence analysis as it is, or is there a problem only with isInvariantLoad?

In D74559#1874435, @SjoerdMeijer wrote:

Perhaps I have missed it, but are the test that have been changed here actually doing any 32 -> 64 converts?

I've attached a standalone example:

In D74488#1872608, @amccarth wrote:

I'll look at this more later today, but here are my initial thoughts.

ClangScanDeps/vfsoverlay test can fail on Windows

"can fail"? Are you saying the results are flaky? I haven't seen this test fail.

I never saw a situation where an external path could start with C:/ rather than C:\. The keys for VFS are sometimes weird hybrids of Posix and Windows styles, but I can't figure out how a VFS lookup would result in an absolute path with that kind of prefix.

Move DefaultParsedAttrInfo out of file scope, and move custom appertains-to function generation out of the loop in EmitClangAttrParsedAttrImpl so we only need to use one output stream.

In D73194#1851155, @samparker wrote:

Even when adding SDNPHasChain to the node description?

In D73194#1849170, @dmgreen wrote:

Is it possible for arm_cmpfpe have both a chain and a glue? I presume it's the cmp that would need the chain, not anything else that gets expanded?