Richard Biener <rguent...@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. Thanks, Richard
