https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #13 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
I understand the concern with undefined values, since it then becomes less
obvious whether e.g.:
a = undef
b = a == a
is guaranteed to be true, or whether it reduces to:
b = undef == undef
which is presumably undef.
But I don't think a null operand really helps. The same question would apply
to:
x = COND_LEN_ADD (a, b, null, len, bias)
y = x == x
vs.
x1 = COND_LEN_ADD (a, b, null, len, bias)
x2 = COND_LEN_ADD (a, b, null, len, bias)
y = x1 == x2
Do both of these ys evaluate to true, or is one or both be undefined?
So if we're prepared to accept undefinedness, I'd prefer to have a “proper”
representation of it. We could probably adopt LLVM's semantics for undef.
(SVE might have some uses for this too.)
