This is the mail archive of the
mailing list for the GCC project.
Re: [i386] Replace builtins with vector extensions
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 10 Apr 2013 09:46:44 +0200
- Subject: Re: [i386] Replace builtins with vector extensions
- References: <alpine dot DEB dot 2 dot 02 dot 1304071030320 dot 4934 at stedding dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 02 dot 1304082243070 dot 3872 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc1iONVnTjKJ1gfqtP7Yyf+7PSYb4ZoCUbdVkks1k7tYfg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1304091056001 dot 29379 at stedding dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 02 dot 1304092041260 dot 3873 at laptop-mg dot saclay dot inria dot fr>
On Tue, Apr 9, 2013 at 9:15 PM, Marc Glisse <email@example.com> wrote:
> On Tue, 9 Apr 2013, Marc Glisse wrote:
>> On Tue, 9 Apr 2013, Richard Biener wrote:
>>> I seem to remember discussion in the PR(s) that the intrinsics should
>>> (and do for other compilers) expand to the desired instructions even when
>>> the corresponding instruction set is disabled.
>> emmintrin.h starts with:
>> #ifndef __SSE2__
>> # error "SSE2 instruction set not enabled"
> Oh, re-reading your post, it looks like you mean we should change the
> current behavior, not just avoid regressions...
> My opinion on the intrinsics is that they are the portable way to use
> vectors on x86, but they are not equivalent to asm (which people should use
> if they don't want the compiler looking at their code). Knowingly generating
> SSE code with -mno-sse is not very appealing.
> However, the arguments in:
> make sense. I guess I'll forget about this patch.
Note that to fully support emitting intrinsics "correctly" even without -msse
x86 specific builtins need to be used and they need to conditionally expand
to either UNSPECs (if the required instriuction set / modes are not available)
or regular RTL (where they can be folded to generic GIMPLE earlier
then as well).
A complication is register allocation which would need to understand how to
allocate registers for the UNSPECs - even if some of the modes would not
be "available". So it's indeed a mess ...
That said, folding of the x86 builtins to GIMPLE looks like a more
that would not interfere too much with any possible route we would go here.
As suggested previously please add a new target hook with the same interface
as fold_stmt in case you want to work on this.
> Marc Glisse