[off-list]
Kenneth Zadeck <zadeck@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]