This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [trans-mem, aa64, arm, ppc, s390] Fixing PR68964
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 12 Jan 2016 15:52:54 -0500
- Subject: Re: [trans-mem, aa64, arm, ppc, s390] Fixing PR68964
- Authentication-results: sourceware.org; auth=none
- References: <56952F79 dot 20901 at redhat dot com>
On Tue, Jan 12, 2016 at 11:53 AM, Richard Henderson <rth@redhat.com> wrote:
> The problem in this PR is that we never got around to flushing out the vector
> support for transactions for anything but x86. My goal here is to make this as
> generic as possible, so that it should Just Work with existing vector support
> in the backend.
>
> In addition, if I encounter other unexpected register types, I will now copy
> them to memory and use memcpy, rather than crash.
>
> The one piece of this that requires a tiny bit of extra work is enabling the
> vector entry points in libitm.
>
> For x86, we make sure to build the files with SSE or AVX support enabled. For
> s390x, I do the same thing, enabling z13 support. I suppose we might need to
> check for binutils support, but I'd rather do this only if necessary.
>
> For arm I'm less sure what to do, since I seem to recall that use of Neon sets
> a bit in the ELF header. Which presumably means that the binary could no
> longer be run without neon, even though the entry points wouldn't be used.
>
> For powerpc, I don't know how to select Altivec if VSX isn't already enabled,
> or indeed if that's the best thing to do.
VSX is an extension of Altivec (VMX) -- VSX always includes Altivec.
If VSX is enable, Altivec will be enabled and available.
Thanks, David