Richard Biener <richard.guent...@gmail.com> writes:
> On Mon, Nov 18, 2013 at 10:08 AM, Richard Sandiford
> <rdsandif...@googlemail.com> wrote:
>> Jeff Law <l...@redhat.com> writes:
>>> On 11/16/13 05:53, Richard Sandiford wrote:
>>>> After the patch that went in yesterday, all calls to host_integerp and
>>>> tree_low_cst pass a constant "pos" argument. This series replaces each
>>>> function with two separate ones:
>>> [ ... ]
>>> So I've almost entirely ignored the whole wide-int conversion discussion
>>> and I suspect I'm not entirely alone.
>>>
>>> Can you briefly summarize what's y'all are trying to accomplish with the
>>> wide-int changes?
>>
>> At the moment, we can only handle tree and rtl integer constants that
>> fit in 2 HOST_WIDE_INTs. The idea is to remove that limit. E.g. things
>> like OImode (used in a few ports) will become a first-class citizen,
>> with all OImode values being representable.
>>
>> Besides that headline reason, there are various side benefits. E.g.:
>>
>> - All INTEGER_CSTs can be viewed either in their TYPE_PRECISION or in
>> "infinite" precision, which isn't possible for 128-bit constants today.
>> (I.e. there's no way to distinguish signed and unsigned 128-bit constants
>> in a double_int.)
>>
>> - Wider-than-2-HWI intermediate results can be represented as a single
>> integer. I'm told this is useful for VRP. (wide-int is mostly Kenny
>> and Mike's work, I've just been butting in recently.)
>>
>> - rtl-level constant folding can use the same code to handle all
>> combinations of CONST_INT and CONST_DOUBLE (and CONST_WIDE_INT,
>> on converted ports). At the moment we handle CONST_INT cases
>> specially, and don't try as hard with CONST_DOUBLEs.
>>
>> Implementation-wise, it tries to make it so that the common single-HWI
>> cases are still fast.
>
> Sadly CONST_WIDE_INTs don't get a mode:
>
> rtx
> immed_wide_int_const (const wide_int &v, enum machine_mode mode)
> {
> ...
> /* It is so tempting to just put the mode in here. Must control
> myself ... */
> PUT_MODE (value, VOIDmode);
> CWI_PUT_NUM_ELEM (value, len);
>
> so much for an incentive to get more targets converted...
> (only after all targets are converted we possibly can merge CONST_INT
> and CONST_WIDE_INT).
Yeah, but the other requirement for merging CONST_INT and CONST_WIDE_INT
is that they both treat the mode field in the same way. Which means that
all existing CONST_INT code needs to be converted to store the mode first.
Changing whether CONST_WIDE_INT stores a mode is trivial compared to that.
Adding modes to the rtx integer constants is something I definitely want
to do (and have some local patches towards), but it's going to take a while.
Until then I think it would just be too confusing to have a TImode 0
stored without a mode but a TImode 1 << 100 (say) stored with a mode.
In the meantime, the incentive for converting targets is so that we can
stop using CONST_DOUBLE for integers. Plus the interfaces are IMO nicer
with wi::...
Thanks,
Richard
