This is the mail archive of the
mailing list for the GCC project.
Re: wide-int branch now up for public comment and review
- From: Richard Biener <rguenther at suse dot de>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Mike Stump <mikestump at comcast dot net>, r dot sandiford at uk dot ibm dot com
- Date: Thu, 29 Aug 2013 10:42:05 +0200 (CEST)
- Subject: Re: wide-int branch now up for public comment and review
- Authentication-results: sourceware.org; auth=none
- References: <520A9DCC dot 6080609 at naturalbridge dot com> <87ppt4e9hg dot fsf at talisman dot default> <alpine dot LNX dot 2 dot 00 dot 1308281040230 dot 20077 at zhemvz dot fhfr dot qr> <521E7FD5 dot 9000602 at naturalbridge dot com>
On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
> > > > Note that the bits above the precision are not defined and the
> > > > algorithms used here are careful not to depend on their value. In
> > > > particular, values that come in from rtx constants may have random
> > > > bits.
> > Which is a red herring. It should be fixed. I cannot even believe
> > that sentence given the uses of CONST_DOUBLE_LOW/CONST_DOUBLE_HIGH
> > or INTVAL/UINTVAL. I don't see accesses masking out 'undefined' bits
> > anywhere.
> I can agree with you that this could be fixed. But it is not necessary to
> fix it. The rtl level and most of the tree level has existed for a long time
> by doing math within the precision.
> you do not see the masking at the rtl level because the masking is not
> necessary. if you never look beyond the precision you just do not care.
> There is the issue with divide and mod and quite frankly the code on the trunk
> scares me to death. my code at the rtl level makes sure that everything is
> clean since i can see if it is a udiv or a div that is enough info to clean
> the value up.
> > > I have a feeling I'm rehashing a past debate, sorry, but rtx constants
> > > can't
> > > have random bits. The upper bits must be a sign extension of the value.
> > > There's exactly one valid rtx for each (value, mode) pair. If you saw
> > > something different then that sounds like a bug. The rules should already
> > > be fairly well enforced though, since something like (const_int 128) --
> > > or (const_int 256) -- will not match a QImode operand.
> > See. We're saved ;)
> this is richard's theory. There is a block of code at wide-int.cc:175 that
> is ifdefed out that checks to see if the rtl consts are canonical. if you
> bring it in, building the libraries fails very quickly. The million dollar
> question is this the only bug or is this the first bug of a 1000 bugs. Your
> comment about not seeing any masking cuts both ways. There is very little
> code on the way in if you create ints with GEN_INT that makes sure someone has
> done the right thing on that side. So my guess is that there are a lot of
> failures and a large number of them will be in the ports.
Well, clearly RTL code _expects_ constants to be properly extended. I
can reproduce the bug and I simply guess that's a matter of mismatching
modes here (or performing an implicit truncation without properly
extending the constant).
10082 mask_rtx = GEN_INT (nonzero_bits (varop, GET_MODE
10085 = simplify_const_binary_operation (code,
uses of GEN_INT are frowned upon ... for exactly that reason - the
mask_rtx is not a proper RTL constant for SImode.
Btw, all this isn't a reason to not have a well-defined wide-int
representation. You just have (as you have for trees) to properly
canonize the representation at the time you convert from RTL
constants to wide-int constants.
In the long run we want a uniform representation of constants
so we can do zero-copying - but it looks like we now have
three different representations - the tree one (sign or zero
extended dependent on sign), RTL (garbage as you show) and
wide-int (always sign-extended).
That's why I was looking at at least matching what tree does
(because tree constants _are_ properly canonized).