This is the mail archive of the gcc-patches@gcc.gnu.org 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: PING: Don't reload PLUS expr within subreg matched by match_operator


I was a bit surprised at the negative feedback on this patch,
so I'm worried I might have failed to explain the situation properly.

When simplifying combined instructions, combine expresses some lowpart
expressions as subregs.  I think it's done this for a long time.
(I'm sure I remember seeing it quite a few years ago.)  Consequently,
many ports have patterns that match subregs of arithmetic expressions.
The following CPUs' .md files have them:

    arm (in iwmmxt.md)
    rs6000 (in rs6000.md)
    i386 (in i386.md)
    sparc (in sparc.md)

That's every primary CPU expect MIPS.  The following CPUs also have them:

    s390 (in s390.md)
    sh (in sh.md)

This isn't a complete list.

Adam came across a case in which we need a subreg pattern for MIPS.
We could do the same as the other ports, and hard-code the subreg in
mips.md.  This is what Adam's original patch did, and it works fine
without any target-independent changes.  I could approve that patch
as-is (and will do so if this reload patch really isn't acceptable).

But I didn't want to hard-code the subreg for two reasons:

   - My understanding is that we don't really want to subregs here
     in the long term.  (Commentary on this thread bears this out.)

   - MIPS is bi-endian, and the subreg offset depends on endianness.
     We'd therefore need different patterns for big- and little-endian
     targets.

We can avoid both problems by replacing the hard-coded subreg
with a match_operator.  This match_operator can match lowpart subregs
and TRUNCATEs, thus avoiding the first problem.  The predicate can also
use subreg_lowpart_p, thus avoiding hard-coded offsets.

I can see that this wouldn't be justifiable if the target-independent
changes were dubious.  But my understanding is that it's nonsensical
for "X" constraints to allow something that empty constraints don't.

"X" already prevents the reloading of a SUBREG_REG.  This is no accident;
it was a self-contained change:

2006-06-09  Andreas Krebbel  <krebbel1@de.ibm.com>

	* reload.c (find_reloads): Unset force_reload for 'X' constraint.

See:

    http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00343.html

for details.

Bernd (as a reload expert), do you disagree about the "X" vs. "" thing?

Richard


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