peephole vs. scheduler

[Dale Johannesen]

On Tuesday, May 8, 2001, at 06:27  AM, David Edelsohn wrote:

>>>>>> dalej  writes:
>
> Dale> I have a case where I'd like to combine two insn's into one late 
> in the
> Dale> game.  I have a nice short define_peephole that does just what I
> Dale> want.[*]
>
> Dale> [*] I tried various combinations of define_insn, define_expand and
> Dale> define_split without success.  Possibly I'm missing something; 
> details
> Dale> available on request [probably Wed.], but they don't affect the 
> main
> Dale> point here.
>
> 	If you are considering define_peephole, define_insn, and
> define_expand, are you sure that you want a GCC-style peephole and not a
> combiner pattern?

The instructions I want to combine aren't created until the reload 
phase, so I don't think this will work.  Let me expand on the problem.  
Loading FP constants into FP regs, the rs6k compiler produces something 
like this:

lis r4,ha16(LC0)
la r12,lo16(LC0)(r4)
lfd f7,0(r12)

It could produce:

lis r4,ha16(LC0)
lfd f7,lo16(LC0)(r4)

I can make it generate high/lo_sum early, but this has no effect; the 
reload code keys off the REG_EQUIV, and ignores the rtl that's there.  
That code always generates the constant address into a register, then 
(several functions later) loads from the register.  I don't see any 
hooks in the reload code to change that.  I doubt that touching that 
code is a good idea, but even if you think so, that change would be 
larger and more spread out than what I suggested.

I'd be delighted to learn a better way to do this.

On Monday, May 7, 2001, at 09:33  PM, law@redhat.com wrote:

|  Ugh.  Gross.  Don't to that.
|  define_peephole2 or something close to that.

I don't understand this suggestion.  Could you expand?

Thanks for the replies.