Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 12 07:11:14 PDT 2017
On 04/11/2017 08:52 AM, Jonas Paulsson wrote:
>>> Has anyone any idea on how to best handle this? Can LSR "split" an
>>> IV to use an extra register? Or would this need to be done in a
>>> target specific pass?
>> When you say "an extra address register" would this imply LSR adding
>> an additional PHI?
> Yes, that would have worked well at least in this type of loop. Can
> LSR do this?
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 experimented with adding a check for 12 bit offsets distance in
> isProfitableIncrement() (checking against all members of the chain),
> which resulted in several chains being produced by LSR, instead of
> just one. The chains that now formed now had immediate offsets that
> were close to each other, so that they should result in addresses with
> 12 bit offsets. But, to my disappointment, LSR did not handle these
> different chains by generating new PHI-nodes for each of them (or by
> skipping those that ended up with just one store in the chain), but
> instead it still output the stores in the same way as before.
> 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).
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev