On Tue, Jan 12, 2016 at 11:53 AM, Richard Henderson <r...@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
