Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Given how messy this is becoming and the amount of duplicated code for what are very similar patterns, does this not just want to be custom lowering? TableGen is starting to feel like the wrong tool for this.
Also, just a side thought: how does all this interact with using the integers for things like load or store offsets? Do we end up not being able to fold an immediate into the load/store as a result of some of these optimisations and thus lose out overall on large-offset addressing when B is enabled?
I’m not sure custom lowering is the right tool either. Making OR/XOR Custom will likely have other effects. Maybe custom isel in RISCVISelDAGToDAG?
These are immediates being used only by an OR/XOR so I don’t think it affects loads/stores folding. Am I missing something?
How about make the duplicate parts of the two PatLeaf to a function, and then call it in the two PatLeaf? This way would make it more readable and clear.
I do not think ISelDagToDag is good, it even introduces more lines than current form.
I have uploaded a new version, in which the duplicate part is dropped to a function and called in the two ParLeaf.
My comment on the previous patch was about constants like 2051 that can be done with
ORI a0, 3
BSETI a0, 11
I don't think this patch handles that.
llvm/test/CodeGen/RISCV/rv64zbs.ll | ||
---|---|---|
1389 | This isn't really an improvement. |
llvm/test/CodeGen/RISCV/rv64zbs.ll | ||
---|---|---|
1389 | It saves an extra register. |
llvm/test/CodeGen/RISCV/rv64zbs.ll | ||
---|---|---|
1389 | With 32 registers, is that an important optimization? Are we also going to implement (BSETI (BSETI (BSETI))) for cases with 3 set bits where none are in the lower 11 bits so we can't use ORI/XORI? It starts getting out of hand. |
llvm/test/CodeGen/RISCV/rv64zbs.ll | ||
---|---|---|
1389 | Thanks. I will just handle the simplest case currently. |
I have changed my code to cover the simlest case, with the sign bit of simm12 handled in the same way as upper bits.
This isn't really an improvement.