This expands the VMOVRRD(extract(..(build_vector(a, b, c, d)))) pattern, to also handle insert_vectors. Providing we can find the correct insert, this helps further simplify patterns by removing the redundant VMOVRRD.
Details
Diff Detail
Event Timeline
llvm/test/CodeGen/ARM/dagcombine-anyexttozeroext.ll | ||
---|---|---|
47 | This is a bit unfortunate, but if you run the code through opt it is already simplified to a single zext, which still becomes a vmovl; vmovl pair |
llvm/test/CodeGen/ARM/dagcombine-anyexttozeroext.ll | ||
---|---|---|
47 | Just for my understanding, what does that mean? Is this something we have to live with, or can we fix this regression? |
llvm/test/CodeGen/ARM/dagcombine-anyexttozeroext.ll | ||
---|---|---|
47 | I don't think it's a real regressions. The mid-end of llvm will have turned it into other code already, which we already optimize to the pair of vmovl's. The test has a lot of inserts and extract's which are unlikely to come up in reality. |
Last question: do we have BE tests for this?
llvm/test/CodeGen/ARM/dagcombine-anyexttozeroext.ll | ||
---|---|---|
47 | Ok, thanks for clarifying. |
I hadn't forgotten to _test_ BE, but yeah none of these tests were BE. I've added one.
This is a bit unfortunate, but if you run the code through opt it is already simplified to a single zext, which still becomes a vmovl; vmovl pair