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

[Hans-Peter Nilsson]

On Fri, 21 Jan 2005, Ulrich Weigand wrote:
> Hans-Peter Nilsson wrote:
> > On Thu, 20 Jan 2005, Ulrich Weigand wrote:
> > > A crucial optimization for the bzip2 case is thus to combine a
> > > mem-to-reg load into such an AND and form a mem-to-reg zero-extend
> > > pattern from it.  However, the AND in question necessarily uses a
> > > paradoxical subreg, so we have this situation:
> >
> > No, I don't think it's necessary, or at least that the bugs
> > that make it seem necessary should be fixed.
>
> If you use AND to express zero-extend (which is b.t.w. the default
> method optab uses), then you necessarily need to use a paradoxical
> subreg (of a REG).  I do not see how this constitutes a bug ...

I mean in a *longer* (or medium-term) perspective paradoxical
mem subregs should go away.  Of course we can't get rid of
paradoxical mem subregs without making sure that we don't lose
anything major, like ports relying on some aspect of them for
performance!

> I mean the reasoning that a paradoxical subreg of a MEM necessarily
> implies "widening a MEM access".

Um, but not until the access is done, to avoid side-effects of
the specific access mode.  But it seems we agree on that.

>  As I said, a paradoxical MEM
> subreg (in the absence of LOAD_EXTEND_OP) is supposed to have exactly
> the same meaning as loading that MEM (in its original mode) into a
> register, and then accessing a paradoxical subreg of that register.

Yep.

> I see I had misinterpreted the somewhat lengthy discussion; I
> had thought that after the gen_lowpart_for_combine patch (which I
> agree is correct) was applied, you were still seeing a bug.

Yes: no.  (or perhaps: "I agree on with the above sentence". :-)

> > I don't see your argument why actually widening is ok.  Perhaps
> > I missed the forest for the trees?
>
> Actually widening the MEM is *not* OK.  B.t.w. this is also what
> gen_lowpart_for_combine did wrong before you patch: it would
> replace a mem:HI with a mem:SI in your example.  This is *wrong*,
> even if it had computed the address properly.

Right, that's the working theory, but I really would like to
check again; I do think I stopped a wrongful construct that
wasn't just the fault of the other bug.

brgds, H-P