On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
<zad...@naturalbridge.com> wrote:
> On 04/24/2013 09:36 AM, Richard Biener wrote:
>>
>> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
>> <rdsandif...@googlemail.com> wrote:
>>>
>>> Richard Biener <richard.guent...@gmail.com> writes:
>>>>
>>>> Can we in such cases please to a preparatory patch and change the
>>>> CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
>>>> mode precision first?
>>>
>>> I'm not sure what you mean here. CONST_INT HWIs are already
>>> sign-extended
>>> from mode precision to HWI precision. The 8-bit value 0xb10000000 must
>>> be
>>> represented as (const_int -128); nothing else is allowed. E.g.
>>> (const_int 128)
>>> is not a valid QImode value on BITS_PER_UNIT==8 targets.
>>
>> Yes, that's what I understand. But consider you get a CONST_INT that is
>> _not_ a valid QImode value. Current code simply trusts that it is, given
>> the context from ...
>
> And the fact that it we have to trust but cannot verify is a severe problem
> at the rtl level that is not going to go away. what i have been strongly
> objecting to is your idea that just because we cannot verify it, we can thus
> go change it in some completely different way (i.e. the infinite precision
> nonsense that you keep hitting us with) and it will all be ok.
Appearantly it is all ok because that's exactly what we have today (and
had for the last 25 years). CONST_INT encodes infinite precision signed
values (with the complication that a QImode 0x80 isn't valid, thus all
modes are signed as well it seems). CONST_DOUBLE encodes infinite
precision signed values as well. Just the "infinite" is limited by the size
of the encoding, one and two HOST_WIDE_INTs.
The interpretation of those "infinite" precision constants is based on
the context (the operation mode of the operation we apply to a CONST_INT
or CONST_DOUBLE). Thus CONST_INT and CONST_DOUBLE do
not have a mode or precision but VOIDmode so "different mode" 1
can be shared (which is probably the original reason of that design
decision).
> I have three problems with this.
>
> 1) Even if we could do this, it gives us answers that are not what the
> programmer expects!!!!!!
> Understand this!!! Programmers expect the code to behave the same way if
> they optimize it or not. If you do infinite precision arithmetic you get
> different answers than the machine may give you. While the C and C++
> standards allow this, it is NOT desirable. While there are some
> optimizations that must make visible changes to be effective, this is
> certainly not the case with infinite precision math Making the change to
> infinite precision math only because you think is pretty is NOT best
> practices and will only give GCC a bad reputation in the community.
Note that as I tried to explain above this isn't a change. _You_ are
proposing a change here! Namely to associate a precision with a _constant_.
What precision does a '1' have? What precision does a '12374' have?
It doesn't have any. With this proposed change we will have the possibility
to explicitely program mismatches like
simplify_binary_operation (PLUS_EXPR, HImode,
wide_int_rtx (SImode, 27),
wide_int_rtx (QImode, 1))
even if _only_ the desired mode of the result matters! Because given the
invariant that a wide-int is "valid" (it doesn't have bits outside of
its precision)
it's precision does no longer matter!
> Each programming language defines what it means to do constant arithmetic
> and by and large, our front ends do this the way they say. But once you go
> beyond that, you are squarely in the realm where an optimizer is expected to
> try to make the program run fast without changing the results. Infinite
> precision math in the optimizations is visible in that A * B / C may get
> different answers between an infinite precision evaluation and one that is
> finite precision as specified by the types. And all of this without any
> possible upside to the programmer. Why would we want to drive people to
> use llvm????? This is my primary objection. If you ever gave any reason
> for infinite precision aside from that you consider it pretty, then i would
> consider it. BUT THIS IS NOT WHAT PROGRAMMERS WANT!!!!
Programming languages or prettiness is not in any way a reason to do
infinite precision math. All-caps or pretty punctuation does not change that.
Infinite precision math is what we do now. What I ask for is to make
separate changes separately. You want larger and host independent
integer constants. Fine - do that. You want to change how we do
arithmetic? Fine - do that. But please separate the two. (well, I'm
likely still going to object to the latter)
> 2) The rtl level of GCC does not follow best practices by today's standards.
> It is quite fragile.
It works quite well.
> At this point, the best that can be said is that it
> generally seems to work. What you are asking is for us to make the
> assumption that the code is in fact in better shape than it is. I
> understand that in your mind, you are objecting to letting the back ends
> hold back something that you believe the middle ends should do, but the
> truth is that this is a bad idea for the middle ends.
I don't quite understand this. What am I objecting to letting the back ends
hold back?
> 3) If i am on a 32 bit machine and i say GEN_INT (0xffffffff), i get a 32
> bit word with 32 1s in it. There is no other information. In particular
> there is no information that tells me was that a -1 or was that the largest
> positive integer. We do not have GEN_INTS and a GEN_INTU, we just have
> GEN_INT. Your desire is that we can take those 32 bits and apply the lt_p
> function, not the ltu_p or lts_p function, but an lu_p function and use that
> to compare those 32 bits to something. At the rtl level there is simply
> not enough information there to sign extend this value. This will never
> work without a major rewrite of the back ends.
Nono, I did not request that you get away with ltu_p or lts_p. I said
it would be _possible_ to do that. Currently (I just believe Richard here)
a positive QImode value 255 CONST_INT does not exist (well, it
does, but sign-extended and thus not distinguishable from -1) - correct?
Given the wide-int encoding in your last patch there is no reason to
disallow a positive QImode value 255 CONST_INT as we can perfectly
distinguish all values from -128 to 255 for QImode values as the encoding
uses extra bits to carry that information. What is complicating things
is that to properly sign- or zero-extend a result according to the operation
mode you also need a desired signedness (that's an issue currently, too,
of course - nothing new here). If you want a QImode add of 127 and 1
then you have to know whether the result is to be interpreted as
signed 8-bit value or unsigned 8-bit value. Because that has an influence
on the encoding result (it doesn't matter if you view the 8 lower bits in the
"arbitrary precision" result 128 in twos-complement term of course).
Richard.
