patch to canonize small wide-ints.

[Richard Sandiford]

Richard Biener <rguenther@suse.de> writes:
> On Tue, 24 Sep 2013, Kenneth Zadeck wrote:
>> On 09/24/2013 09:39 AM, Richard Biener wrote:
>> > On Tue, 17 Sep 2013, Kenneth Zadeck wrote:
>> > 
>> > > Richi,
>> > > 
>> > > This patch canonizes the bits above the precision for wide ints with types
>> > > or
>> > > modes that are not a perfect multiple of HOST_BITS_PER_WIDE_INT.
>> > > 
>> > > I expect that most of the changes in rtl.h will go away.   in particular,
>> > > when
>> > > we decide that we can depend on richard's patch to clean up rtl constants,
>> > > then the only thing that will be left will be the addition of the
>> > > TARGET_SUPPORTS_WIDE_INT test.
>> > > 
>> > > I do believe that there is one more conserved force in the universe than
>> > > what
>> > > physicist's generally consider: it is uglyness.  There is a lot of truth
>> > > and
>> > > beauty in the patch but in truth there is a lot of places where the
>> > > uglyness
>> > > is just moved someplace else.
>> > > 
>> > > in the pushing the ugly around dept, trees and wide-ints are not canonized
>> > > the
>> > > same way.    I spent several days going down the road where it tried to
>> > > have
>> > > them be the same, but it got very ugly having 32 bit unsigned int csts
>> > > have
>> > > the upper 32 bits set.   So now wide_int_to_tree and the wide-int
>> > > constructors
>> > > from tree-cst are now more complex.
>> > > 
>> > > i think that i am in favor of this patch, especially in conjunction with
>> > > richards cleanup, but only mildly.
>> > > 
>> > > There is also some cleanup where richard wanted the long lines addressed.
>> > > 
>> > > Ok to commit to the wide-int branch?
>> > Looks good to me.
>> > 
>> > I'll be doing a separate review of the to/from tree parts when I
>> > find time to do that, but that's unrelated to this patch.
>> > 
>> > Thanks,
>> > Richard.
>> as i said on irc, after i check in a cleaned up version of this (for ppc) i
>> will change the rep for unsiged tree-csts so that they have an extra block of
>> zeros if their top bit is set.   this will clean that up somewhat.
>
> Yes, this will give wide-ints a sign (as I originally proposed).

No, nothing changes on that front.  An N-bit wide_int has no sign.
It looks the same whether it came from a signed tree constant,
an unsigned tree constant, or an rtx (which also has no sign).

All the posted patch does is change the internal representation of
excess bits, which are operationally don't-cares.  The semantics are
just the same as before.  And the point of the follow-up change that
Kenny mentioned is to avoid a copy when treating an N-bit INTEGER_CST
as a wider-than-N wide_int in cases where we're extending according to
TYPE_SIGN.  I.e. it's purely an optimisation.  The resulting wide_int
storage is exactly the same as before, we just do less work to get it.

Thanks,
Richard