This is the mail archive of the
mailing list for the GCC project.
Re: peephole vs. scheduler
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: peephole vs. scheduler
- From: Dale Johannesen <dalej at apple dot com>
- Date: Wed, 9 May 2001 10:37:25 -0700
- Cc: dalej at apple dot com, gcc at gcc dot gnu dot org, law at redhat dot com
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;
> Dale> available on request [probably Wed.], but they don't affect the
> 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
It could produce:
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, firstname.lastname@example.org 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.