This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks.
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Jakub Jelinek <jakub at redhat dot com>, Eric Botcazou <ebotcazou at adacore dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
- Date: Mon, 19 May 2014 09:58:13 -0700
- Subject: Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks.
- Authentication-results: sourceware.org; auth=none
- References: <20131112123633 dot GC34333 at msticlxl57 dot ims dot intel dot com> <201401022318 dot 15106 dot ebotcazou at adacore dot com> <CAFULd4bqaCZcJZmqZ9Cj=5vUJzofKJWg2hDxCm=-2g6yte66zQ at mail dot gmail dot com> <201401031220 dot 34808 dot ebotcazou at adacore dot com> <CAFULd4ZvCFhW=VhhQ89Zp6KYPVjjDET6f71cu-iEFCBDmTFBtQ at mail dot gmail dot com> <20140103115939 dot GF892 at tucnak dot redhat dot com> <CAFULd4bhLUho1Yj9m5=vvpEFvyk5XGEhY5SdTjrzgDxN6s2Oqw at mail dot gmail dot com> <CAFULd4a8g2GCLYkBpXoszsofmCbienNZzqNHxOqEB_n3rjCFpw at mail dot gmail dot com> <20140519044801 dot GA12624 at atrey dot karlin dot mff dot cuni dot cz> <CAFULd4Ymfa8wx2Pgi=t_zh9DwAPXYdbhM86=dTWdD4xR8bv9xw at mail dot gmail dot com> <CAMe9rOqvged6m_RGXLf2BiLjKqtb5LZ0ni_n6sS=8VYOsaXFOg at mail dot gmail dot com> <CAFULd4YhGtNSNXDZdU5oAGmhRhFqkKWJ3XPAcEesXT4yNvEgqA at mail dot gmail dot com>
On Mon, May 19, 2014 at 9:45 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> 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?
>
Kirill, do we have performance data for excessive alignment
vs ABI alignment?
--
H.J.