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*: Kenneth Zadeck <zadeck at naturalbridge dot com>*Cc*: Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, Mike Stump <mikestump at comcast dot net>*Date*: Wed, 16 Oct 2013 19:45:22 +0100*Subject*: Re: [wide-int] int_traits <tree>*Authentication-results*: sourceware.org; auth=none*References*: <alpine dot LNX dot 2 dot 00 dot 1310161537220 dot 11149 at zhemvz dot fhfr dot qr> <525EB50F dot 2090003 at naturalbridge dot com>

Kenneth Zadeck <zadeck@naturalbridge.com> writes: >> I note that we immediately return in the above case, so >> >> if (precision < xprecision + HOST_BITS_PER_WIDE_INT) >> { >> len = wi::force_to_size (scratch, val, len, xprecision, >> precision, UNSIGNED); >> return wi::storage_ref (scratch, len, precision); >> } >> >> applies only when the desired precision is a multiple of a HWI. > yes >> I assume it adds that extra zero word in case the MSB is set, >> right? > yes >> I am confused about the condition written here and >> how we look at precision and not xprecision when deciding how >> to extend - given a 8-bit precision unsigned 0xff and precision == 64 >> we do not even consider sign-extending the value because we look >> at precision and not xprecision. Don't we need to look at >> xprecision here? > I do not think so. There are three cases here: > > 1) xprecision < precision: > say xprecision = 8 and precision = 32. > > The number is between 0 and 255 and after canonicalization the number > will be between 0 and 255. > > 2) xprecision == precision > not much to talk about here. > > 3) xprecision > precision > > We need to loose the upper bits of the input and it does not matter what > they were. The only thing that we are concerned about is that the > bits above what is now the sign bit pointed to by precision are matched > in the bits above precision. (3) is gone with the assert though. As mentioned in my message yesterday, I thought your new way of canonising unsigned tree constants meant that there was always an upper zero bit. Is that right? If so, xprecision < precision is a no-op, because the number always has the right form for wider precisions. The only difficult case is xprecision == precision, since then we need to peel off any upper -1 HWIs. If that's right and xprecision == precision can use val with an adjusted len, then... >> After all an assert precision == xprecision >> does not work in this routine. >> >> Quickly execute.exp tested only. >> >> To avoid code quality wreckage we have to implement a different way >> of allocating the 'scratch' storage of wide_int_ref_storage >> (well, ideally we wouldn't need it ...). I thought of simply >> allocating it via alloca (), but we need to do that in all >> callers that build a wide_int_ref (eventually via a hidden >> default arg). But as that's a template specialization of >> generic_wide_int ... so the option is to provide a function >> wrapper inside wi:: for this, like > I want richard and mike to be the people who respond to the next > point. I am not a c++ person and all of this storage manager layer > stuff gives me a headache. ...the use of the scratch array goes away completely for addr_wide_int and max_wide_int. If this code is on a hot path for wide_int then maybe we should simply require that wide_int operations involving trees have explicit extensions, like in rtl. (I.e. only do the implicit extension for addr_wide_int and max_wide_int.) I'm not opposed to going back to a separate scratch array if all else fails, but it's really ugly, so I'd like to look at the alternatives first... Thanks, Richard

**Follow-Ups**:**Re: [wide-int] int_traits <tree>***From:*Kenneth Zadeck

**References**:**[wide-int] int_traits <tree>***From:*Richard Biener

**Re: [wide-int] int_traits <tree>***From:*Kenneth Zadeck

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

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