Re: patch to enable LRA for ppc

[Vladimir Makarov <vmakarov at redhat dot com>]

On 13-10-21 2:55 PM, Michael Meissner wrote:
> On Mon, Oct 21, 2013 at 08:18:22PM +0200, Steven Bosscher wrote:
> > On Mon, Oct 21, 2013 at 5:51 PM, Michael Meissner wrote:
> > > What I'm doing is adding secondary reload support so that up until reload time,
> > > we can represent VSX addresses as reg+offset, and in secondary reload, create
> > > the addition instructions to put the offset in a base register.  I haven't made
> > > any changes to the machine independent portions of the compiler.  As long as
> > > IRA uses the secondary reload interface, it should be ok.  However, right now,
> > > I need to focus most of my attention on getting the secondary reload support to
> > > work.
> > >
> > > One thing that I've asked for before, but to remind you, is I really, really
> > > wish secondary reload could allocate two scratch registers if it is given an
> > > insn that takes 4 arguments.  Right now, I'm allocating a TFmode scratch, since
> > > that gives 2 registers, but future changes will want TFmode to go into a single
> > > vector register, and I will need to create another type, like V4DI that does
> > > take 2 registers.  The case that this is needed for is moving an item from GPRs
> > > to VSX registers that takes 2 GPR registers, such as moving 128-bit items in
> > > 64-bit mode, or 64-bit items in 32-bit mode.  I need two registers to do the
> > > move into, and then I will do the combine operation.
> >
> > Eh, perhaps I'm missing something, but...
> >
> > Isn't one of the great advantages of LRA over reload, that LRA allows
> > you to create new pseudos so that you shouldn't ever need secondary
> > reloads??
> You still need secondary reload.
As I understand, Mike is telling about secondary_reload hook.  LRA can 
generate chain of reloads as long as it is needed.  It is achieved by 
subsequent processing generated reload insns on one or more 
lra-constraints subpasses.  Porting LRA frequently consists of removing 
secondary reload hook as in many cases it is smart enough to find 
necessary reloads just from insns constraints.  But there are still 
really complicated situations when LRA can not do this and it still 
needs directions from secondary_reload hook.  I am sure PPC has real 
needs to use this hook even for LRA.
> For example, on the powerpc, you have 5 addressing modes for GPRs and FPRS:
>
>      1) base register
>      2) base register + index register
>      3) base register + offset
>      4) auto-update for base register + index register
>      5) auto-update for base register + offset register
>
> Now for VSX registers you only have:
>
>      1) base register
>      2) base register + index register
>
> So, in the work I'm doing right now, I want to allow reg + offset addressing,
> but if the register being loaded is an Altivec register (high part of the VSX
> registers), I need to create a secondary reload to load the offset into and
> then convert the address to indirect or indexed addressing.  You don't want to
> always disallow offset based addressing, but you want to create the secondary
> reload when you need to.
>
> Similarly, vector types can do indexed addressing (reg+reg) but if you are
> loading or storing the value into GPR registers, you can't do reg+reg
> addressing on multi-word items.
>
> Finally, one of the features of ISA 2.07 is the notion of load fusion, where
> the hardware will fuse together a load immediate with an adjacent load (for
> GPRs, you need the load immediate shifted to be the register that is being
> loaded, for VSX registers, you just need the instructions adjacent).  In this
> case, before reload we will want to pretend that the machine has addressing to
> include the fusion forms, and in secondary reload, you will generate the
> combined insn that will become the fusion instruction.