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?
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.
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.
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]
