This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Combine performance regression (was: Fix PR target/18701)

On Thu, 20 Jan 2005, Roger Sayle wrote:
> On Thu, 20 Jan 2005, Ulrich Weigand wrote:
> > Thus, I do not like this patch ;-)
> Agreed.

Not agreed.

> My apologies for the confusion, when I approved H-P's patch I
> thought it was doing something completely different.  The mistake
> I made was to believe that the comment above this hunk actually
> described it's behaviour; "Don't change the mode of the MEM..."

It doesn't?

> This explains why I suggested a revised ChangeLog of:
>         PR target/18701
>         * combine (combine_simplify_rtx): Do not widen the mode used
>         to access the MEM of a paradoxical subreg.
> instead of H-P's
>         PR target/18701
>         * combine.c (combine_simplify_rtx): Do not allow paradoxical
>         subregs of MEM.

No, we've been through that already.  The reason is that "widen
the mode used to access the MEM of a paradoxical subreg" is a
tautology.  And it's not stopping paradoxical subregs
everywhere, just from being simplified into a widened access

> Re-reading this patch and the code immediately following it which I'd
> assumed this change was guarding, the above patch really is disallowing
> all paradoxical subregs of MEMs, which as you point out is completely
> inappropriate.

I think I got lost here somehow.  Can you please tell why the
widening is ok here?  Or do you mean there was no widening?

Can we go back to the RTL in my original analysis and say why it
would be ok to widen the access?

brgds, H-P

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]