On 05/03/2013 09:02 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:45 PM, Kenneth Zadeck <zad...@naturalbridge.com> wrote:
On 05/03/2013 07:19 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
<rdsandif...@googlemail.com> wrote:
Richard Biener <richard.guent...@gmail.com> writes:
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).
I think this is the fundamental disagreement. Your last step doesn't
follow. RTL integer modes are neither signed nor unsigned. They are
just a collection of N bits. The fact that CONST_INTs represent
smaller-than-HWI integers in sign-extended form is purely a represential
detail. There are no semantics attached to it. We could just as easily
have decided to extend with zeros or ones instead of sign bits.
Although the decision was made before my time, I'm pretty sure the
point of having a canonical representation (which happened to be sign
extension) was to make sure that any given rtl constant has only a
single representation. It would be too confusing if a QImode 0x80 could
be represented as either (const_int 128) or (const_int -128) (would
(const_int 384) then also be OK?).
No, not as value for a QImode as it doesn't fit there.
And that's the problem with using an infinite-precision wide_int.
If you directly convert a CONST_INT representation of 0x80 into a
wide_int, you will always get infinite-precision -128, thanks to the
CONST_INT canonicalisation rule. But if you arrive at 0x80 though
arithmetic, you might get infinite-precision 128 instead. These two
values would not compare equal.
That's true. Note that I am not objecting to the canonicalization choice
for the RTL object. On trees we do have -128 and 128 QImode integers
as tree constants have a sign.
So we clearly cannot have wide_int make that choice, but those that
create either a tree object or a RTL object have to do additional
canonicalization (or truncation to not allow a QImode 384).
Yes, I'm again arguing that making choices for wide_int shouldn't be
done because it seems right for RTL or right for how a CPU operates.
But we are mixing two things in this series of patches - introduction
of an additional RTX object kind CONST_WIDE_INT together with
deciding on its encoding of constant values, and introduction of
a wide_int class as a vehicle to do arithmetic on the host for larger
than HOST_WIDE_INT values.
The latter could be separated by dropping CONST_DOUBLE in favor
of CONST_WIDE_INT everywhere and simply providing a
CONST_WIDE_INT <-> double-int interface (both ways, so you'd
actually never generate a CONST_WIDE_INT that doesn't fit a double-int).
Given the tree world, i am surprised that you would push in this direction.
While i do see some benefit for having two reps for ints at the rtl level, I
understand the argument that is one too many.
The target_supports_wide_int is a transitional trick. The idea is to move
the ports away from using CONST_DOUBLE at all for ints. Not only is this a
step towards putting a mode in an rtl int const, but it also would allow the
floating point world to move beyond the limits that sharing the rep with
integers imposes.
One of the big goals of this cleanup is to get rid of the three path
implementation for integer math:
constant fits in HWI - good implementation.
constant fits in 2 HWIs - spotty implementation.
constant needs more than 2 HWIs - ice or get wrong answer.
Doing a trick like this just makes it harder to unify everything into the
good implementation category.
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.
It encodes an N-bit integer. It's just that (assuming non-power-of-2
modes) several N-bit integers (with varying N) can be encoded using the
same CONST_DOUBLE representation. That might be what you meant, sorry,
and so might seem pedantic, but I wasn't sure.
Yes, that's what I meant. Being able to share the same RTX object for
constants with the same representation but a different mode is nice
and looks appealing (of course works only when the actual mode stored
in the RTX object is then sth like VOIDmode ...). That we have gazillions
of NULL pointer constants on trees (for each pointer type) isn't.
Richard.
4 gb of memory is less than $30US. We need to move on. The pain that no
mode causes is significant.
I think you should stop arguing that way as you two confuse me with
two opposite views here. Richard says having no mode on constants
is very much fine (but it would be convenient to have one). You say
you absolutely want a mode but you do not add one to CONST_WIDE_INT.
?
different people have different opinions. however, the reality is
that rtl constants have an implied mode, that is just not stored with
constant.
Btw, I arrived at reviewing the patches for the introduction of wide_int
(separate from the RTL side) as vehicle of eventually replacing double-int.
It has good design goals but you get yourself too much influenced by
what you think are RTL/tree weaknesses or strengths.
Replacing double-int is my subgoal. It is what is necessary to get to
the place where gcc has robust support for any width integer. There are
large parts of the compiler, at both the tree and rtl level that do not
even use double-int: they just do the operations inline for the fits in
HWI case and fail to try any transformation if it does not fit. And i
would point out that all of those places are explicitly math within a
fixed precision.
Now I feel being dragged into a RTL IL discussion ... which isn't my
primary area of knowledge (nor interest). Unfortunately nobody else
but the patch authors and me seem to be keen enough to get involved here ...
I agree.
Just to ask again - is there a branch to look at the patches and produce
patches against?
I answered that at the bottom of the refresh of the 4th patch yesterday.
Richard.
