This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: paradoxical subreg problem
- From: Michael Matz <matzmich at cs dot tu-berlin dot de>
- To: Jeffrey A Law <law at redhat dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Mon, 28 Jan 2002 20:36:06 +0100 (MET)
- Subject: Re: paradoxical subreg problem
Hi,
On Mon, 28 Jan 2002 law@redhat.com wrote:
> I'll start simple. On a big endian machine, can this expression be optimized
> into true/false at compile time, or must it be run-time computed?
>
> (eq (subreg:SI (mem/s:QI (plus:SI (reg:SI 3 %r3)
> (const_int 15 [0xf])) 1) 0)
> (mem/s:SI (plus:SI (reg:SI 3 %r3)
> (const_int 12 [0xc])) 1))
>
> Think very very carefully about the semantics of a paradoxical subreg.
>
> According to my reading, the compiler is allowed to optimize the expression
> into (true) because the bits outside of QImode on the subreg are "don't care
> bits" -- meaning they can have any value that is convenient to us.
>
> Agree/Disagree?
Disagree. Richard H. pointed out that paradoxical subreg of mem are
normally not allowed, so this shouldn't happen, and Richard K. later
transformed it into what reload would do to this, and concludes that this
optimization is valid. I disagree to the latter for deeper reasons:
The non-touched bit's of paradoxical subregs (be they from mem or from
pseudos) are _not_ "don't care". They are "we don't know", i.e.
undefined. Any optimizations making use of knowledge of the content of
those bits must be invalid. In some very constrained circumstances we
might relax that (e.g. when we know that byte-loading will zero-extend).
In those cases we of course shouldn't simply rely on
(use (subreg:SI (reg:QI x) 0) ...) doing the right thing, but instead
make that knowledge explicit, e.g. by
(use (zero_extend:SI (reg:QI x))
I.e. replace paradoxical subregs by known operations, and if we can't, due
to lack of knowledge or other reasons, inhibit any optimizations referring
to the undefined parts. The documentation seems to be misleading: it
talks about forming subregs, when the code doesn't care about the other
bits. If that is correct combine shouldn't have produced that subreg of
mem, because clearly we _do_ care about those other bits in the compare.
OTOH once such a subreg is produced we can't deduce anything anymore.
So this is twofold: may be it was too difficult to prove that we don't
care about those bits (cf. combine), so such subregs are produced in the
hope to get better code later. Then we should deactivate optimizations
making use of knowledge about undefined bits (i.e. when we later see, that
we do care nontheless).
Or we could get rid of paradoxical subregs ;-) They are so paradoxical.
Ciao,
Michael.