Jonas Paulsson via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 17 22:28:57 PDT 2017
> No, LSR won't add new PHIs. This is a long-standing deficiency (and
> also, in part, prevents it from properly handling pre/post-inc
> addressing modes, which motives some target-specific passes such as
I do find in this regression that gcc manages to use four address
registers, while llvm uses just one, with a lot of extra address
building instructions as a result, where the gcc loop looks very clean.
I suspect that this could be a needed feature. Would you recommend doing
this (splitting PHIs) as a "LSRPrep" pass, perhaps in the target, or
would you try to extend LSR itself?
>> I also see that LSR is thinking in terms of increments between the
>> memory accesses. In the loop I am working with it's disappointing to
>> see that before each memory access, the base address is loaded into
>> register, and then the offset is added, and then the access, which is
>> 3 instructions. It should have been just an add/sub after the
>> previous access before the memory access, per LSRs intentions. I
>> wonder where this is supposed to be handled: In some sort of target
>> pre-isel pass that chains the GEPs? Or is this just folded more often
>> on other targets?
> As I recall, it does not do this now (although this is also needed for
> handling pre/post-inc addressing modes properly).
Same question - It might be simpler to do a separate post-LSR GEP
handling (in CodeGenPrepare, perhaps?), but I suspect it would also be
possible to extend LSR to do this instead?
More information about the llvm-dev