On Wed, Apr 5, 2017 at 10:00 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Wed, Apr 05, 2017 at 09:42:31AM +0200, Uros Bizjak wrote:
>> On Tue, Apr 4, 2017 at 9:24 PM, Jakub Jelinek <ja...@redhat.com> wrote:
>> > Hi!
>> >
>> > aggregate_value_p is called often very early during compilation, e.g.
>> > from allocate_function or during gimplification of a call with lhs.
>> > The problem with that is e.g. that on x86_64 -m64 -mno-sse we can't
>> > include <x86intrin.h>, because the always_inline inline functions
>> > in mmx and 3dnow intrinsic headers return __m64 or take __m64 as arguments
>> > and that in the 64-bit ABI is in SSE register.
>> >
>> > The following patch makes sure we diagnose this only later (e.g. when
>> > expanding a function to RTL or when expanding calls to other functions),
>> > which means we don't diagnose e.g. inline functions that got successfully
>> > inlined (because then there is really no function return in SSE or x87
>> > reg) or e.g. for builtin calls if they are emitted inline rather than
>> > as a library call (again, I think that is desirable).
>> > I had to tweak a few tests because the reported line changed slightly,
>> > and in the last test add -fno-builtin-fminl, because otherwise fminl
>> > is expanded inline and again there is no call left with the problem.
>> >
>> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>> No, I think the issue should be fixed in intrinsics.
>
> But then you can't use the mmx intrinsics in pure mmx non-sse code, even
> when my patch allows that. Say:
> #include <x86intrin.h>
>
> __attribute__((target ("nosse,mmx"))) void
> mmx_only (__m64 *a, __m64 *b, __m64 *c)
> {
> *a = _mm_packs_pu16 (*b, *c);
> }
>
> or without the attribute, but in -mno-sse -mmmx compilation.
> This compiles just fine for -m32 and there is no reason why it couldn't
> work similarly for -m64, when the intrinsic will be inlined there is no
> return nor argument needed in SSE registers.
> So in effect it makes MMX unusable for 64-bit code without SSE.
> Or do we just declare that unsupported? Of course, people shouldn't be
> using MMX, especially not in 64-bit code.
Oh, I forgot to point out that on x86_64 ABI specifies MMX values in
SSE registers. So, on x86_64, users should not compile MMX code with
-mno-sse.
The problem, as reported in the PR was that <x86intrin.h> can't be
used with -mno-sse, even when source code that includes header does't
use SSE or MMX on x86_64. But, when these intrinsics are *used*, we
should still warn on x86_64. So the warning in your example is
correct.
Uros.
