On Tue, Nov 14, 2017 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> So what I am now thinking is that the only practical answer is to stop
>> gcc from believing that it is safe to use 16-aligned instructions on
>> int128's. (Some reading on the net suggests that the actual performance
>> penalty for that is minimal anyway on modern Intel chips.)
>
> Concretely, the attached patch fixes it for me. I've verified by
> examining the assembly code that this stops gcc from using movdqa or
> movaps in numeric.c, except for one place where it apparently can
> prove that it's dealing with a sufficiently-aligned local variable.
I am not seeing any difference in the assembly code generated by gcc
-S with and without your patch. Perhaps I am missing something? What
are you actually seeing?
> As I said before, I don't like moving the int128 typedefs into a section
> where they don't belong, but that's just cosmetic --- this is good enough
> for testing.numeric.s.HEAD
Section 3 could be moved after the section 4 listing the alignment
macros. It seems that it won't hurt to back-patch the refactoring as
well.
--
Michael