On Wed, Mar 7, 2012 at 6:40 PM, Ulrich Weigand wrote:
> Richard Kenner wrote:
>
>> > Given the current set of results, since I do not have any way to verify
>> > whether my simplify_set changes would actually trigger correctly, I'd
>> > rather propose to just remove the SUBREG case in apply_distri
Richard Kenner wrote:
> > Given the current set of results, since I do not have any way to verify
> > whether my simplify_set changes would actually trigger correctly, I'd
> > rather propose to just remove the SUBREG case in apply_distributive_law
> > (i.e. only apply the first patch below).
> >
> I tried to implement that suggestion, but interestingly enough I cannot
> really test it since I was unable to find any single case where that
> SUBREG case in apply_distributive_law actually causes any difference
> whatsoever in generated code.
>
> Do you have any further suggestion of how to f
Richard Kenner wrote:
> > Maybe the best solution would be to remove the SUBREG case from the generic
> > apply_distributive_law subroutine, and instead add a special check for the
> > distributed subreg case right at the above place in simplify_set; i.e. to
> > perform the inverse distribution onl
> Maybe the best solution would be to remove the SUBREG case from the generic
> apply_distributive_law subroutine, and instead add a special check for the
> distributed subreg case right at the above place in simplify_set; i.e. to
> perform the inverse distribution only if it is already guaranteed
Richard Kenner wrote:
> > > The problem appears to be that an RTX expression like
> > >
> > > (minus:QI (subreg:QI (reg:SI 64 [ a ]) 0)
> > > (subreg:QI (reg:SI 66 [ b ]) 0))
> > >
> > > seems to be considered non-canonical by combine, and is instead
> > > transformed into
> > >
> [Richard, combine question at the bottom for you. I've quoted Ulrich's
> whole message in order to provide a bit of context.]
I don't remember ALL of this, but can perhaps make a few hints.
> > The problem appears to be that an RTX expression like
> >
> > (minus:QI (subreg:QI (reg:SI 64 [
[Richard, combine question at the bottom for you. I've quoted Ulrich's
whole message in order to provide a bit of context.]
"Ulrich Weigand" writes:
> Richard Sandiford wrote:
>> At the moment, fwprop will propagate constants and registers
>> even if no further rtl simplifications are possible:
On 01/11/2012 05:55 PM, Ulrich Weigand wrote:
In either case, it is always odd to have RTX in the insn stream
that isn't "stable" under common simplication ... Do you have
any suggestions on how to fix this? If we add the fwprop patch,
should we then disable apply_distributive_law for SUBREGs?
Richard Sandiford wrote:
> At the moment, fwprop will propagate constants and registers
> even if no further rtl simplifications are possible:
>
> if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
> flags |= PR_CAN_APPEAR;
>
> What do you think about extending this to subregs?
I've been testin
On 09/14/2011 05:44 PM, Richard Sandiford wrote:
> A SUBREG may not be REG nor CONSTANT. Don't you need
> to check REG_P/CONSTANT_P on SUBREG?
Yeah, good point. There should be a "&& REG_P (SUBREG_REG (new_rtx))"
in there. Probably also worth checking for non-paradoxical subregs.
I was g
"H.J. Lu" writes:
> On Wed, Sep 14, 2011 at 8:24 AM, Richard Sandiford
> wrote:
>> At the moment, fwprop will propagate constants and registers
>> even if no further rtl simplifications are possible:
>>
>> if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
>> flags |= PR_CAN_APPEAR;
>>
>> What do y
On Wed, Sep 14, 2011 at 8:24 AM, Richard Sandiford
wrote:
> At the moment, fwprop will propagate constants and registers
> even if no further rtl simplifications are possible:
>
> if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
> flags |= PR_CAN_APPEAR;
>
> What do you think about extending this
At the moment, fwprop will propagate constants and registers
even if no further rtl simplifications are possible:
if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
flags |= PR_CAN_APPEAR;
What do you think about extending this to subregs? The reason for
asking is that on NEON, vector loads like
14 matches
Mail list logo