Hi Ho! On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote: > > So while trapping variants can certainly be introduced it looks like > > this task may be more difficult. > > I don't think you need to introduce trapping tree codes. You can > introduce them directly in the front-end as > > s = x +nv y > (((s ^ x) & (s ^ y)) < 0) ? trap () : s
Could you please kindly explain a bit about it? Suppose s, x, and y are 8-bit signed integer. If x and y are -128, s = (-128) + (-128), which will overflow. Now if suppose s is 0, ((0 ^ -128) & (0 ^ -128)) == -128, which is less than zero and will trap. This is correct. But, if s is -128, ((-128 ^ -128) & (-128 ^ -128)) is zero and will not trap. This is incorrect, isn't this? In short, why should s be included in the calculation? Is it assumed that s is always zero? Thank you very much for the explanation. > d = x -nv y > (((d ^ x) & (x ^ y)) < 0) ? trap () : d > > (b == INT_MIN ? trap () : -nv b) > > (int)((long long) a * (long long) b) == a *nv b ? trap () : a *nv b > > Making sure they are compiled efficiently is another story, but > especially for the sake of LTO I think this is the way to go. > > Paolo -- Best regards, Eus (FSF member #4445) In this digital era, where computing technology is pervasive, your freedom depends on the software controlling those computing devices. Join free software movement today! It is free as in freedom, not as in free beer! Join: http://www.fsf.org/jf?referrer=4445
