This is the mail archive of the gcc@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: paradoxical subreg problem


law@redhat.com writes:

> In message <200201282037.PAA24126@makai.watson.ibm.com>, David Edelsohn writes:
>  > >>>>> Richard Kenner writes:
>  > 
>  > Richard> Let me rephrase: why are we genering this if we don't know what tho
>  > se
>  > Richard> bits are?
>  > 
>  > 	I agree with Kenner.  There are two things we can discuss: should
>  > this ever be generated and should this be generated in this particular
>  > instance causing problems.  Regardless whether this compare result can be
>  > determined at compile-time or run-time, if the bits are undefined, why is
>  > GCC generating an expression that relies on undefined bits?
> Kenner's initial claim was not that they were undefined, but that they were
> bits we could pretend had any value that was interesting to us (don't care).
> If you read the section on paradoxical subregs, this is what it implies.
> 
> I think we really need to clarify if the bits are "don't care" or "undefined";
> once that's settled it shouldn't be terribly difficult to deal with combine
> to make it follow those semantics.
> 
> I think the semantics should be "undefined".

I think you're using the word "undefined" in a confusing way.  You
probably mean "opaque".  If the expression (subreg:SI (mem:QI ...))
had no defined value in the high bits, then the generator of the
expression should know this, and so presumably the value of the bits
doesn't affect the computation and the rest of the compiler can pick
any convenient value.

In this particular case, though, IMO either way the bug is in the
generator of the RTL.  We know that the bits will actually be zero,
and so either we rely on this and a ZERO_EXTEND should be used, or we
don't care what the bits will be, in which case the SUBREG is valid no
matter which definition of it we choose.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>


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