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.
Note, my patch apparently doesn't handle the above, there is still the
aggregate_value_p call in NRV.
So maybe we should also not error if:
(cfun && current_ir_type () == IR_GIMPLE && !currently_expanding_to_rtl)
or so.
Jakub
