https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sure, before that we would punt much earlier at simplification of the
non-sensical subreg.
I don't mind if simplify_subreg doesn't call native_encode_rtx in the cases
where it ICEs and instead fails.
But, I believe what gen_lowpart_for_combine does for comparisons is completely
wrong for non-scalar modes that are different from their previous mode.
A same sized subreg of something is reinterpretation of the bits of something
as something else, VIEW_CONVERT_EXPR or type punning through union.
Changing the mode of a comparison isn't like that.
Consider:
typedef char __v8qi __attribute__((vector_size (8)));
void
foo (int x, __v8qi *y)
{
union U { __v8qi v; unsigned long long l; } u;
u.l = x > 36;
*y = *y + u.v;
}
on x86_64-linux, I see (subreg:V8QI (gt:DI (reg:CCGC 17 flags) (const_int 0
[0])) 0) in the dumps but for some reason gen_lowpart_for_combine actually
hasn't been called except to convert originally gt:QI to gt:DI (that is
correct). If it would be called, it would turn it into a completely bogus
(gt:V8QI (reg:CCGC 17 flags) (const_int 0 [0])), which isn't clear what it
actually would mean.
(gt:V8QI (reg:V8QI ...) (reg:V8QI ...)) performs 8 comparisons and fills in the
resulting vector with 8 0/-1 values, similarly (gt:V8QI (reg:V8QI ...)
(const_vector:V8QI ...)). But if both operands of the comparison are scalar
and result is a vector, what it is?
