This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] x86: _mm*_undefined_* (for real)
- From: Ulrich Drepper <drepper at gmail dot com>
- To: Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 24 Mar 2014 07:18:41 -0400
- Subject: Re: [PATCH] x86: _mm*_undefined_* (for real)
- Authentication-results: sourceware.org; auth=none
- References: <87r45vygtj dot fsf at x240 dot local dot i-did-not-set--mail-host-address--so-tickle-me> <20140324063131 dot GB17283 at msticlxl57 dot ims dot intel dot com>
On Mon, Mar 24, 2014 at 2:31 AM, Kirill Yukhin <kirill.yukhin@gmail.com> wrote:
> If list of missing intrinsics is big - maybe you could share it? I can
> help you implementing it.
So far only the set1 intrinsics. I'll see whether I can spot more.
> In general, I think _undefined idea is correct and the patch is doing most
> important thing - it localizes undef semantics in couple of built-ins.
> However I don't know which code is optimal to model undef behaviour.
Indeed, that's my main objective for now. Then someone with more
knowledge of the gcc internals could experiment with the code
generation and only have to change a few places. I could make one
more change, if wanted, and reduce the number of affected locations to
just three. We would only need a builtin to create, say,
_mm_undefined_esi128. The other two 128-bit values could be created
using a cast which gcc allows just fine. Should I do that? Looks a
bit less clean but helps with maintainability IMO.
In general, as for the other patch, too late for the next release?