On Thu, Aug 25, 2005 at 06:49:06PM +0530, Ashwin Kolhe wrote:
> I am actually trying to find out WHY and WHEN peep2_reg_dead_p
> was introduced.
When the peephole2 pass was introduced. Another feature of the
peephole2 pass is that we can allocate *new* scratch registers,
and the pattern fails to
On Aug 25, 2005, at 6:19 AM, Ashwin Kolhe wrote:
I am actually trying to find out WHY and WHEN peep2_reg_dead_p
was introduced. I checked the mailing list but dint find anything
relavent.
Did you do a cvs diff/log and hunt it down, read the check-in
comment, then find a PR number and read it,
On Thu, Aug 25, 2005 at 02:02:48PM +0530, Ashwin wrote:
> However if the pattern happens to be something like this :
>
> op0 = 1
> op0 = op0 leftshift op2
Ah, I see. Well, peep2_reg_dead_p doesn't include "or_set" in its
definition, so it shouldn't do what you're suggesting. I wouldn't
be oppos
> Do you mean the source code? A hint: grep ^func_name *.c will get to it
> for every function in gcc.
>
> In this case it is in recog.c, look at peep2_reg_dead_p but also
> peep2_regno_dead_p. There are other peep2_* functions you may use.
>
> Paolo
I am sorry.. I think u got me wrong. I have
Ashwin Kolhe wrote:
On 8/25/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
I consider this to be less readable than the peep2 way to do it,
especially if your peephole2 had three or four instructions. And
peep2_regno_dead_p uses an array (a circular buffer) so it's more
efficient. Indeed dea
On 8/25/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> I consider this to be less readable than the peep2 way to do it,
> especially if your peephole2 had three or four instructions. And
> peep2_regno_dead_p uses an array (a circular buffer) so it's more
> efficient. Indeed dead_or_set_p even has
operands[0] == operands[1] || peep2_regno_dead_p (2, operands[0])
Exactly.. this is the same thing as calling dead_or_set_p(insn,
operands[0]).
i am sorry, since we are using peephole2, the variable "insn" points
to the first insn in the template and not the last. so the call should
be
On 8/25/05, Ashwin Kolhe <[EMAIL PROTECTED]> wrote:
> > You'll have something like this in your test
> >
> > operands[0] == operands[1] || peep2_regno_dead_p (2, operands[0])
> >
> > i.e. you only need to test for op0's death if it is different from op1.
> >
> > Paolo
> >
>
> Exactly.. this is the
> You'll have something like this in your test
>
> operands[0] == operands[1] || peep2_regno_dead_p (2, operands[0])
>
> i.e. you only need to test for op0's death if it is different from op1.
>
> Paolo
>
Exactly.. this is the same thing as calling dead_or_set_p(insn,
operands[0]). If it can
Ashwin wrote:
The problem in front of me is something like this..
op0 = 1
op1 = op0 leftshift op2
This will be optimized to
op1 = 1 leftshift op2 (by the peephole2 pass to the rtl pattern
corresponding to this and hence the requirement that op0 should be dead
after insn2)
However if the pat
The problem in front of me is something like this..
op0 = 1
op1 = op0 leftshift op2
The above is a part of the template to be matched, with one of the
conditions that op0 should be dead after the 2nd insn.
This will be optimized to
op1 = 1 leftshift op2 (by the peephole2 pass to the rtl patter
On Wed, Aug 24, 2005 at 06:50:25PM +0530, Ashwin wrote:
> The pattern matches in the original peephole pass because the
> peephole pass happens just before assembly generation, when the 3 insns
> are present together. Has anybody encountered a similar problem?
No, or at least havn't looked.
>
12 matches
Mail list logo
