This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks.


On Mon, May 19, 2014 at 6:42 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

>>> Uros,
>>> I am looking into libreoffice size and the data alignment seems to make huge
>>> difference. Data section has grown from 5.8MB to 6.3MB in between GCC 4.8 and 4.9,
>>> while clang produces 5.2MB.
>>>
>>> The two patches I posted to not align vtables and RTTI reduces it to 5.7MB, but
>>> But perhaps we want to revisit the alignment rules.  The optimization manuals
>>> usually care only about performance critical loops.  Perhaps we can make the
>>> rules to align only bigger datastructures, or so at least for -O2.
>>
>> Based on the above quote, "Misaligned data access can incur
>> significant performance penalties." and the fact that this particular
>> alignment rule has some compatibility issues with previous versions of
>> gcc (these were later fixed by Jakub), I'd rather leave this rule as
>> is. However, if the access is from the cold section, we can perhaps
>> avoid extra alignment, while avoiding those compatibility issues.
>>
>
> It is excessive to align
>
> struct foo
> {
>   int x1;
>   int x2;
>   char x3;
>   int x4;
>   int x5;
>   char x6;
>   int x7;
>   int x8;
> };
>
> to 32 bytes and align
>
> struct foo
> {
>   int x1;
>   int x2;
>   char x3;
>   int x4;
>   int x5;
>   char x6;
>   int x7[9];
>   int x8;
> };
>
> to 64 bytes.  What performance gain does it provide?

Avoids "significant performance penalties," perhaps?

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]