- When memory intrinsics, such as memcpy, the attached scoped AA metadata is not passed down to the backend. As a result, the backend cannot schedule relevant memory operations around them following that hint. In this patch, SelectionDAG is enhanced to propagate that metadata (scoped AA only) when they are lowered into loads and stores.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/CodeGen/AArch64/memcpy-scoped-aa.ll | ||
---|---|---|
1 | Precommit new tests? |
llvm/test/CodeGen/AArch64/memcpy-scoped-aa.ll | ||
---|---|---|
61 | You may want to add a test for @llvm.memcpy.inline.p1i8.p1i8.i64 as well. |
Include tests examining the MIR to ensure scoped AA metadata are attached on loads/stores lowered from mem ops.
I added some remarks.
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
6423 | IMHO, the expansion of the mem intrinsic should be responsible for only using the metadata that makes sense for it ? !alias.scope and !noalias make sense, with the meaning: this memory instruction might alias with '!alias.scope` scopes, and will never alias with !noalias scopes. | |
llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | ||
5730 | See above: the expansion itself should be responsible for taking the elements that it gets. | |
llvm/test/CodeGen/AArch64/memcpy-scoped-aa.ll | ||
80 | Can we also have the check for the other instructions (with scope info) at MIR level ? |
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
6423 | That's reasonable. I just moved the preparation of that AAInfo into the lowering part from the builder. So far, scoped AA metadata are retained. But, TBAA ones are cleared so far. We may take advantage of tbaa.struct in the future to refine loads/stores generated. |
IMHO, the expansion of the mem intrinsic should be responsible for only using the metadata that makes sense for it ?
(If not, we should have an assertion to check that the AAInfo is sane).
!alias.scope and !noalias make sense, with the meaning: this memory instruction might alias with '!alias.scope` scopes, and will never alias with !noalias scopes.
!tbaa does not make sense (I think), but !tbaa.struct does. The expansion might make use of it, or leave away.