public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Don't error about x86 return value in SSE reg (or x86 reg) or argument in SSE reg too early (PR target/80298)
Date: Wed, 05 Apr 2017 08:00:00 -0000	[thread overview]
Message-ID: <20170405080007.GN17461@tucnak> (raw)
In-Reply-To: <CAFULd4YxXU=wwE0Yygime6RMMWiR3RwrH=vRXeoGsF8CNoOwsQ@mail.gmail.com>

On Wed, Apr 05, 2017 at 09:42:31AM +0200, Uros Bizjak wrote:
> On Tue, Apr 4, 2017 at 9:24 PM, Jakub Jelinek <jakub@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

  reply	other threads:[~2017-04-05  8:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-04 19:24 Jakub Jelinek
2017-04-05  7:42 ` Uros Bizjak
2017-04-05  8:00   ` Jakub Jelinek [this message]
2017-04-05  8:12     ` Uros Bizjak
2017-04-05  8:20       ` Jakub Jelinek
2017-04-05  8:26         ` Uros Bizjak
2017-04-05  8:29           ` Jakub Jelinek
2017-04-05 15:37             ` Uros Bizjak
2017-04-06 18:37               ` Uros Bizjak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170405080007.GN17461@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ubizjak@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).