Alas, using half the available vector registers in a single instruction is just too much for the register allocator to handle. The mve-vldst4.ll test here fails when they are enabled at present. Whilst I look into ways to fix that, this disables the generation of VLD4 by adding a mve-max-interleave-factor option, which we currently default to 2.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/ARM/ARMISelLowering.cpp | ||
---|---|---|
147 | Nit: not sure we need to say "Defaults" to 2 as I don't see much prior art of mentioning the default value (it would also require to keep the message up to date with the value when that gets changed, although that is of course not a really difficult problem). | |
llvm/test/Transforms/LoopVectorize/ARM/mve-vldn.ll | ||
5 | Perhaps silly question, but what happens when we pass -mve-max-interleave-factor=42, i.e. a value > 4? Is input checked? Do we need to mention that acceptable values are 1, 2, and 4? |
llvm/lib/Target/ARM/ARMISelLowering.cpp | ||
---|---|---|
147 | I thought I had seen this in more places, but you are probably right, I'll take that bit out. | |
llvm/test/Transforms/LoopVectorize/ARM/mve-vldn.ll | ||
5 | I was going for not caring about the internal compiler options being given strange values. I think it would likely hit an assert if you put it too high. Hopefully something we don't need to worry about in any case? The nice thing about an option like this is that we can also set it to 1 if we need to disable the vldn's entirely. |
llvm/test/Transforms/LoopVectorize/ARM/mve-vldn.ll | ||
---|---|---|
5 | Agreed. |
Currently this prevents us from compiling quite a few codes, so this LGTM while we sort things out.
Nit: not sure we need to say "Defaults" to 2 as I don't see much prior art of mentioning the default value (it would also require to keep the message up to date with the value when that gets changed, although that is of course not a really difficult problem).