Kenneth Zadeck <zad...@naturalbridge.com> wrote: >I am a little confused here. what is the reason for doing the the >is_sign_extended thing? >is the point of deferring the canonization that we can avoid the use of > >the scratch array until the value is actually used. then we >canonicalize on demand?
Yes. >That seems like it is going to require several bits of state: like one >to say if we have canonicalized or not. All of these will then have >to >be checked on every operation. We simply statically assign this property to an int_traits kind so We can evaluate it at compile-time. >however, i guess if it keeps to alias analyzer sane then I guess it is >ok, but it makes everything else a little more complex. Its indeed solely to make the generated code sane and thus reduce the overhead of the wide-int branch. Richard. >Kenny > > > > >On 10/18/2013 10:57 AM, Richard Sandiford wrote: >> [off-list] >> >> Kenneth Zadeck <zad...@naturalbridge.com> writes: >>> Richi, >>> >>> Do you want me to back out the patch that changes the rep for >unsigned >>> tree-csts? >>> >>> kenny >> Doesn't look like you're on IRC, so FWIW: >> >> <rsandifo> richi: just to check, you still want the scratch array to >be >> separate from the other fields, to avoid the other fields >escaping, >> is that right? [11:13] >> <rsandifo> will try that today if so >> <richi> rsandifo: that would be nice, but I'm not settled yet on what >to do on >> ::decompose fully - the idea of a ::is_sign_extended storage-ref >flag >> popped up [11:17] >> <richi> rsandifo: so eventually we don't need a scratch member >anymore (which >> would be best) >> <richi> rsandifo: so if you can give that idea a take instead ... ;) >[11:18] >> <richi> today I'll try to clear my patch review pipeline ... >> <rsandifo> yeah. Just to be sure: we still need the extra zero HWI >for the >> large unsigned constants though, right? >> <richi> no, in that case we wouldn't need that >> <richi> we'd have extra (conditional) sext() operations in all >sign-dependend >> ops though [11:19] >> <richi> thus delay the canonicalization until the first use >> <rsandifo> I thought the ::is_sign_extended was dealing with a >different case >> (small_prec). The problem with the extra zero HWI is different. >> <richi> no, it would deal with the case in general and say "if you >need a >> sign-extended rep you have to sign-extend" [11:20] >> <rsandifo> but the point of the extra HWI is that if you extend a >64-bit tree >> to 128 bits, you have two signficant HWIs. >> <richi> for the fixed_wide_int rep we then want to combine the >extension with >> the copy in its constructor [11:21] >> <rsandifo> For unsigned constants that extra HWI is zero. For signed >> constants it's minus one. >> <rsandifo> The choice matters in that case, since it affects the >128-bit >> result of any arithmetic >> <richi> but here the interface is just what limits us - the fact that >> decompose allows precision != xprecision [11:22] >> <richi> that case should be split out to a different "decompose" >> <richi> it's just needed for fixed_wide_int AFAIK? >> <rsandifo> But the interface was defined that way to avoid >constructing >> fixed_wide_ints for x and y when doing x + y -> fixed_wide_int >> <rsandifo> we could instead do addition with three different >precisions (x, y >> and the result), but that'd get complicated... [11:23] >> <richi> hmm, I see >> <richi> well, then leave the extra zeros alone for now [11:24] >> <rsandifo> ok, works for me, thanks >> <rsandifo> so for this ::is_sign_extended thing, we basically go back >to the >> original "arbitrary upper bits" as the default (conservative) >> assumption, but add optimisations for the case where >> ::is_sign_extended is a compile-time true? [11:25] >> <richi> yes >> <rsandifo> OK >> <richi> "arbitrary upper bits" would be either sign- or zero-extended >thouhg >> (but it probaly doesn't make a difference to arbtrary) >> <richi> on a tree wide_int_ref would have that "arbitrary upper bits" >> <richi> that in as far as I can see should get rid of scratch >(fingers >> crossing) [11:27] >> <richi> s/on/only/ >> <rsandifo> Right -- that copy wasn't there in Kenny's original >version, it >> only came in because of the "small_prec having defined upper >bits". >> <rsandifo> I agree ::is_sign_extended sounds like a nice compromise >[11:28] >> <richi> let's hope it will work out and improve code as desired ;) >> <richi> also the parts Mike suggested, adding more compile-time known >> optimizations [11:29] >> <rsandifo> yeah >> <richi> and making tree.c predicates use the tree rep directly >> <richi> though then integer_zerop will be magically more efficient >than t == 0 >> ... [11:30] >> <rsandifo> would be nice if we could wi:: to be efficient enough so >that we >> can keep the tree.c bits as-is [11:32] >> <rsandifo> ...could get... [11:33] >> <rsandifo> with CONSTANT (...) tricks or whatever >> <rsandifo> realise that might be a bit optimistic though... >> <richi> yeah [12:41] >>
