By specification, source and destination of llvm.memcpy.* must either be equal or non-overlapping. This semantics is hard or impossible to figure out once lowered. This patch explicitly marks loads from source and stores to destination as not aliasing if source and destination is known to be not equal.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/unittests/Transforms/Utils/MemTransferLowering.cpp | ||
---|---|---|
134–135 | Please remove code after // |
llvm/unittests/Transforms/Utils/MemTransferLowering.cpp | ||
---|---|---|
115–116 | Fragile? Why not simple test to check presence of additional metadata? |
The problem is there is now pass which runs this utility. I'm not aware how to exercise it from lit test. For that reason I had to create a unit test. Is there a way to build a lit test in such case?
llvm/lib/Transforms/Utils/LowerMemIntrinsics.cpp | ||
---|---|---|
79 | According to code style single statement if doesn't need braces. | |
llvm/unittests/Transforms/Utils/MemTransferLowering.cpp | ||
115–116 | I think you are right it should be checking for metadata. On the other hand, my final goal is to make sure the loop is vectorizable. Do you think it's ok to test both cases? | |
134–135 | Sure. |
AMDGPU uses this, see llvm/test/CodeGen/AMDGPU/lower-mem-intrinsics.ll
llvm/lib/Transforms/Utils/LowerMemIntrinsics.cpp | ||
---|---|---|
79 | It's spread over multiple lines with the comment, it should have braces |
In order for this to work I would need to modify AMDGPULowerIntrinsics pass to provide additional argument(result of ScalarEvolutionAnalysis) to expandMemCpyAsLoop. Currently, this pass doesn't depend on SCEV analysis.
Do you mean it's fine to modify AMDGPULowerIntrinsics pass? If that's what you mean I don't see there is enough rational to do a non NFC change just to be able to create a test.
So otherwise upload a new patch which somehow uses this new functionality. What is motivation behind this change? If cannot be tested using current pipeline..
And if there is a one - wait until that one is accepted and you can push that one + this one together.
I'm extending functionality of memory lowering utilities which meant to be used in different context. At the moment there is no any upstream pass which will take advantage of added functionality immediately. Rather, we have downstream functionality which will make use of it. In future, upstream users can decide to utilize the functionality on case by case bases... I don't have enough expertise in those areas to drive changes
Ok, I think we dont think we really need to require lit test and the provided unit test is good enough.
Yes. It's a good improvement either way, and lit tests are much more stable and maintainable than ones directly touching the APIs
LGTM but a lit test would be much more maintainable
llvm/unittests/Transforms/Utils/MemTransferLowering.cpp | ||
---|---|---|
170 | These operands should be swapped to get correct error messages |
llvm/unittests/Transforms/Utils/MemTransferLowering.cpp | ||
---|---|---|
170 | Didn't know. Will fix. Thanks |
llvm/lib/Transforms/Utils/LowerMemIntrinsics.cpp | ||
---|---|---|
481 | Isn't this implied by the usual constraints of memcpy? The source and destination aren't allowed to overlap. Why does this need the SCEV check? |
llvm/lib/Transforms/Utils/LowerMemIntrinsics.cpp | ||
---|---|---|
481 | llvm.memcpy (unlike memcpy) is allowed to have src == dst (but no other overlap). |
Braces