The newly added test previously caused the compiler to fail an
assertion. It looks like a strightforward TypeSize upgrade.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Hi @peterwaller-arm, the patch looks good to me! I wonder if it's worth renaming the test to vscale_load.ll so that it's less specific? That way we can potentially more load related fold tests here in future as well.
llvm/test/Transforms/InstCombine/vscale_load_bitcast.ll | ||
---|---|---|
6 ↗ | (On Diff #380964) | I guess this fold is happening because effectively i1 is being promoted to i8? Otherwise the minimum size of <vscale x 16 x i1> would be just 2 bytes, i.e. less than than <8 x i8>. |
llvm/lib/Analysis/ConstantFolding.cpp | ||
---|---|---|
357 | You cannot use TypeSize in this way. Essentially TypeSize can only prove a positive not a negative. This code block is effectively saying "the following code is only safe when SrcSize >= DestSize and you must exit when this is not true". Whereas you've changed it to be "if and only if I can prove SrcSize < DestSize shall I exit". So I believe the correct change is rather if (!TypeSize::isKnownGE(SrcSize, DestSize))` | |
llvm/test/Transforms/InstCombine/vscale_load_bitcast.ll | ||
6 ↗ | (On Diff #380964) | This is likely due to the issue above but at the same time the test is relying on undefined behaviour. You either want to use a smaller fixed length vector or perhaps add a vscale_range so the load does overlap the store. Can you also add a negative test for the case where the load & store must remain. I guess if you want to tick all the boxes you could also add a test where the store remains but the load is removed. |
llvm/test/Transforms/InstCombine/vscale_load_bitcast.ll | ||
---|---|---|
6 ↗ | (On Diff #380964) | Right. I've added a negative test and fixed up the size query, thanks both for your attention to detail! I considered your comment about vscale_range but:
|
My vscale_range comment is not concerning the implementation but rather about ensuring the ll tests do not contain potentially undefined behaviour. You can ignore this because I've commented below with an alternative that is simpler.
llvm/test/Transforms/InstCombine/vscale_load.ll | ||
---|---|---|
28 | This is potentially undefined behaviour (the load can read beyond the alloca). A better option is for both tests to replace the alloca with a pointer parameter. That way the bounds of the storage are unknown and it becomes only about the store and load. |
You cannot use TypeSize in this way. Essentially TypeSize can only prove a positive not a negative.
This code block is effectively saying "the following code is only safe when SrcSize >= DestSize and you must exit when this is not true". Whereas you've changed it to be "if and only if I can prove SrcSize < DestSize shall I exit".
So I believe the correct change is rather