SROA does not correctly account for offsets in TBAA/TBAA struct metadata.
This patch creates functionality for generating new MD with the corresponding
offset and updates SROA to use this functionality.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
We need a test case with nested structs as well, I somehow have the feeling that doesn't work properly rn.
Also some comments that seem straight forward. For the logic part, I hope someone else could take a look, I'd have to read up on struct TBAA.
llvm/include/llvm/IR/Metadata.h | ||
---|---|---|
645 | Any reason to expose this. If not, maybe make them static members in the AAMDNode struct, potentially hidden. | |
llvm/lib/Analysis/TypeBasedAliasAnalysis.cpp | ||
746 | Style: | |
749 | you push back up to 4 elements, let's go with 4 here too. | |
785 | shouldn't we break at the end? | |
llvm/lib/Transforms/Scalar/SROA.cpp | ||
3388 | No temporary GEPs please. What is wrong with GEP ? | |
3440 | No temporary GEPs please. What is wrong with InBoundsGEP ? |
Very much agreed on someone with more TBAA experience looking over.
I'm not sure that I have the same hunch about nested structs. We only need to modify the offset in the root node so I don't immediately see how nesting presents an issue. Mind elaborating on what you think could go wrong?
llvm/include/llvm/IR/Metadata.h | ||
---|---|---|
645 | I can definitely see other users of such shifting, though if they always use AAMDNodes it will be encapsulated. A public static method seems good to me. | |
llvm/lib/Analysis/TypeBasedAliasAnalysis.cpp | ||
785 | No, we want to extract all of the relevant TBAA.struct pieces. In essence TBAA.struct is a list of triples saying the offset, size, type. There therefore may be several relevant triples. | |
llvm/lib/Transforms/Scalar/SROA.cpp | ||
3388 | The problem is that the GEP instruction itself may be constant folded by the IRBuilder (and thus why it only returns a value and not a gep instruction). | |
3440 | Same reply as above. |
FYI this patch currently causes the TBAA in SROA basictest to fail because (at least from my understanding of TBAA) the TBAA on that memcpy is sized to one byte (meaning only the first part of the copy ends up with TBAA).
I want someone with more TBAA experience to check me on this assumption -- and likewise I assume one byte copy in the test should be changed to indicate the entire memory is of that type and thus the TBAA is propagated?
llvm/lib/Transforms/Scalar/SROA.cpp | ||
---|---|---|
3388 | Hm, do we need this for anything other than struct types? |
llvm/lib/Transforms/Scalar/SROA.cpp | ||
---|---|---|
3388 | When you say struct types do you mean tbaa.struct (used in memcpy), tbaa struct path information, or something else? We definitely need this in tbaa.struct per the memcpy test case. I think we also want it for regular tbaa (e.g. you have a load which uses regular tbaa info and it should have its tbaa with the correct offset). Likewise I can imagine optimization passes other than SROA needing to do this sort of offset procedure (hence my inclination to make the API public for the shifting). |
llvm/lib/Analysis/TypeBasedAliasAnalysis.cpp | ||
---|---|---|
782 | What if the offset is inside the specified region instead of at the boundary ? Shouldn't we keep that with a 0 offset and adapted size ? Although keeping it is not strictly necessary, but then we will loose some tbaa information. |
llvm/lib/Analysis/TypeBasedAliasAnalysis.cpp | ||
---|---|---|
782 | Good call, amended to include. |
All comments have been addressed and it looks certainly reasonable. Due to the lack of TBAA experts, let's go ahead: LGTM
After this commit, this bug started to happen: https://bugs.llvm.org/show_bug.cgi?id=49825. Can you please take a look?
Any reason to expose this. If not, maybe make them static members in the AAMDNode struct, potentially hidden.