On Mon, Nov 1, 2021 at 9:43 AM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Mon, Nov 01, 2021 at 08:27:12AM +0100, Uros Bizjak wrote:
> > > Also, I wonder for all these patterns (previously and now added),
> > > shouldn't
> > > they have && TARGET_64BIT in conditions? I mean, we don't really support
> > > scalar TImode for ia32, but VALID_SSE_REG_MODE includes V1TImode and while
> > > the constant shifts can be done, I think the variable shifts can't, there
> > > are no TImode shift patterns...
> >
> > - (match_operand:SI 2 "const_int_operand")))]
> > - "TARGET_SSE2"
> > + (match_operand:QI 2 "general_operand")))]
> > + "TARGET_SSE2 && TARGET_64BIT"
> >
> > I wonder if this change is too restrictive, as it disables V1TI shifts
> > by constant on 32bit targets. Perhaps we can introduce a conditional
> > predicate, like:
> >
> > (define_predicate "shiftv1ti_input_operand"
> > (if_then_else (match_test "TARGET_64BIT")
> > (match_operand 0 "general_operand")
> > (match_operand 0 "const_int_operand")))
> >
> > However, I'm not familiar with how the middle-end behaves with the
> > above approach - will it try to put the constant in a register under
> > some circumstances and consequently fail the expansion?
>
> That would run again into the assertions that shift expanders must never
> fail.
> The question is if a V1TImode shift can ever appear in 32-bit x86, because
> typedef __int128 V __attribute__((vector_size (16)));
> is rejected with
> error: ‘__int128’ is not supported on this target
> when -m32 is in use, no matter what ISA flags are used.
We can do:
typedef int __v1ti __attribute__((mode (V1TI)));
__v1ti foo (__v1ti a)
{
return a << 11;
}
gcc -O2 -msse2 -m32:
v1ti.c:1:1: warning: specifying vector types with ‘__attribute__
((mode))’ is deprecated [-Wattributes]
1 | typedef int __v1ti __attribute__((mode (V1TI)));
| ^~~~~~~
v1ti.c:1:1: note: use ‘__attribute__ ((vector_size))’ instead
during RTL pass: expand
v1ti.c: In function ‘foo’:
v1ti.c:5:12: internal compiler error: in expand_shift_1, at expmed.c:2668
5 | return a << 11;
| ~~^~~~~
which looks like an oversight of some kind, since TI (and V2TI) mode
errors out with:
v1ti.c:1:1: error: unable to emulate ‘TI’
and
v1ti.c:1:1: error: unable to emulate ‘V2TI’
I will submit a PR with the above issue.
But I agree, V1TI is x86_64 specific, so the added insn constraint is OK.
Thanks,
Uros.
> Jakub
>
