[wide-int] More optimisations

[Kenneth Zadeck]

On 10/29/2013 08:43 AM, Richard Sandiford wrote:
> Richard Biener <rguenther@suse.de> writes:
>> On Sun, 27 Oct 2013, Richard Sandiford wrote:
>>> This patch adds some more optimisations to the wi:: comparison functions.
>>> It uses the:
>>>
>>>    #define CONSTANT(X) (__builtin_constant_p (X) && (X))
>>>
>>> idiom that was mentioned before, except that I thought CONSTANT would be
>>> too easily confused with CONSTANT_P, so I went for CAN_TELL instead.
>>> Better names welcome.
>> STATIC_CONSTANT_P similar to static_assert?
> Sounds good.
>
>>> The changes are:
>>>
>>> - Add a fast path to eq_p for when one of the inputs isn't sign-extended.
>>>    This includes code to handle compile-time 0 specially.
>>>
>>> - Add the opposite optimisation to Mike's lts_p change, if we can tell at
>>>    compile time that it applies.
>> I think the cases Mike added should only be enabled when we can figure
>> them out at compile-time, too.
> Well, the idea with most of these functions was to handle the simple
> "everything is one HWI" cases inline.  For operations like addition this
> needs to be based on the precision, since that's the only cheap way of
> knowing whether the result is also a single HWI.  But for logic operations
> like AND and OR, it can be based on whether the inputs are single HWIs,
> since single-HWI inputs give a single-HWI output.  This catches more cases.
>
> lts_p is a bit like AND and OR in this respect.  fits_shwi_p is the
> same as "len == 1", which is simple to check and is often true.  If we
> restrict the optimisation to STATIC_CONSTANT_P we'll end up using the
> out-of-line comparison for all TREE_INT_CST_LTs, even the int-int ones
> that we currently handle inline.

This has always been my way of looking at it.

kenny
> Thanks,
> Richard
>