This is the mail archive of the
mailing list for the GCC project.
Re: [wide-int] More optimisations
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, mikestump at comcast dot net, rsandifo at linux dot vnet dot ibm dot com
- Date: Tue, 29 Oct 2013 11:21:28 -0400
- Subject: Re: [wide-int] More optimisations
- Authentication-results: sourceware.org; auth=none
- References: <874n82rcpn dot fsf at talisman dot default> <alpine dot LNX dot 2 dot 00 dot 1310291318130 dot 11149 at zhemvz dot fhfr dot qr> <877gcwz1q8 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
On 10/29/2013 08:43 AM, Richard Sandiford wrote:
Richard Biener <email@example.com> 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?
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.