This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Richard Sandiford <rdsandiford at googlemail dot com>*To*: Richard Biener <rguenther at suse dot de>*Cc*: Kenneth Zadeck <zadeck at naturalbridge dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Mike Stump <mikestump at comcast dot net>*Date*: Wed, 28 Aug 2013 12:26:07 +0100*Subject*: Re: wide-int branch now up for public comment and review*Authentication-results*: sourceware.org; auth=none*References*: <520A9DCC dot 6080609 at naturalbridge dot com> <87ppt4e9hg dot fsf at talisman dot default> <alpine dot LNX dot 2 dot 00 dot 1308281040230 dot 20077 at zhemvz dot fhfr dot qr> <878uzmp2lg dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <alpine dot LNX dot 2 dot 00 dot 1308281200380 dot 20077 at zhemvz dot fhfr dot qr>

Richard Biener <rguenther@suse.de> writes: >> So the precision variable is good for the rtl level in several ways: >> >> - As you say, it avoids adding the explicit truncations that (in practice) >> every rtl operation would need >> >> - It's more efficient in that case, since we don't calculate high values >> and then discard them immediately. The common GET_MODE_PRECISION (mode) >> <= HOST_BITS_PER_WIDE_INT case stays a pure HWI operation, despite all >> the wide-int trappings. >> >> - It's a good way of checking type safety and making sure that excess >> bits aren't accidentally given a semantic meaning. This is the most >> important reason IMO. >> >> The branch has both the constant-precision, very wide integers that we >> want for trees and the variable-precision integers we want for rtl, >> so it's not an "either or". With the accessor-based implementation, >> there should be very little cost to having both. > > So what I wonder (and where we maybe disagree) is how much code > wants to inspect "intermediate" results. Say originally you have > > rtx foo (rtx x, rtx y) > { > rtx tem = simplify_const_binary_operation (PLUS, GET_MODE (x), x, > GEN_INT (1)); > rtx res = simplify_const_binary_operation (MINUS, GET_MODE (tem), tem, > y); > return res; > } > > and with wide-int you want to change that to > > rtx foo (rtx x, rtx y) > { > wide_int tem = wide_int (x) + 1; > wide_int res = tem - y; > return res.to_rtx (); > } > > how much code ever wants to inspect 'tem' or 'res'? > That is, does it matter > if 'tem' and 'res' would have been calculated in "infinite precision" > and only to_rtx () would do the truncation to the desired mode? > > I think not. The amount of code performing multiple operations on > _constants_ in sequence is extremely low (if it even exists). > > So I'd rather have to_rtx get a mode argument (or a precision) and > perform the required truncation / sign-extension at RTX construction > time (which is an expensive operation anyway). I agree this is where we disagree. I don't understand why you think the above is better. Why do we want to do "infinite precision" addition of two values when only the lowest N bits of those values have a (semantically) defined meaning? Earlier in the thread it sounded like we both agreed that having undefined bits in the _representation_ was bad. So why do we want to do calculations on parts of values that are undefined in the (rtx) semantics? E.g. say we're adding two rtx values whose mode just happens to be HOST_BITS_PER_WIDE_INT in size. Why does it make sense to calculate the carry from adding the two HWIs, only to add it to an upper HWI that has no semantically-defined value? It's garbage in, garbage out. Providing this for rtl doesn't affect the tree-level operations in any way. Although things like addition require both arguments to have the same precision after promotion, that's trivially true for trees, since (a) the inputs used there -- C integers and tree constants -- can be promoted and (b) tree-level code uses fixed_wide_int <N>, where every fixed_wide_int <N> has the same precision. And you can still do "infinite-precision" arithmetic on rtx constants if you want. You just have to say how you want the constant to be extended (sign or zero), so that the value of all bits is meaningful. Thanks, Richard

**Follow-Ups**:**Re: wide-int branch now up for public comment and review***From:*Richard Biener

**References**:**wide-int branch now up for public comment and review***From:*Kenneth Zadeck

**Re: wide-int branch now up for public comment and review***From:*Richard Sandiford

**Re: wide-int branch now up for public comment and review***From:*Richard Biener

**Re: wide-int branch now up for public comment and review***From:*Richard Sandiford

**Re: wide-int branch now up for public comment and review***From:*Richard Biener

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |