https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> Sure, before that we would punt much earlier at simplification of the
> non-sensical subreg.
We probably should again then?
> I don't mind if simplify_subreg doesn't call native_encode_rtx in the cases
> where it ICEs and instead fails.
I don't think native_encode_rtx (or simplify_immed_subreg) should ICE for
any valid input. This is valid input, for this API.
> 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
No. A subreg of "something" is just invalid RTL. But this isn't about
subregs, it's about lowpart, and I don't see how it is wrong there?
> 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
Which is invalid RTL.
> 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?
Ah sure, we should not change the mode to something not MODE_INT. Your
patch is okay, thanks; but there is more wrong here :-/
