[PATCH] D126576: [RISCV] Add custom isel for (add X, imm) used by load/stores.
Philip Reames via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue May 31 09:36:03 PDT 2022
reames added a comment.
In D126576#3544185 <https://reviews.llvm.org/D126576#3544185>, @craig.topper wrote:
> In D126576#3544140 <https://reviews.llvm.org/D126576#3544140>, @reames wrote:
>
>> Just a thought on an alternate approach. Feel free to ignore.
>>
>> Given:
>> addi a2, a2, Low12C
>> add a2, a0, a2
>>
>> Is there any reason we shouldn't canonicalize toward:
>> add a2, a0, a2
>> addi a2, a2, Low12C
>>
>> That is, try to push the add with immediate towards the users? (Assume a one use restriction on the original addi.)
>>
>> This isn't an optimization per se, but if we could treat it as a canonicalization, I think it simplifies the address matching problem significantly.
>
> Where do you propose to canonicalize it? Another peephole between isel and doPeepholeLoadStoreADDI?
It turns out I had a wrong mental model on SDAG handling of constants. I had been thinking we'd expanded the constant materialization sequences during legalization; looking at an example with debug output, this turns out not to be the case. As such, my assumption that this was just a DAGCombine rule is off base.
Given that, yeah, the structure would seem to require a separate peephole between ISEL and the current address matching. ("between" might be slightly the wrong word here as we could probably fixed point the later two.)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126576/new/
https://reviews.llvm.org/D126576
More information about the llvm-commits
mailing list