This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Vectorizer/alignment
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Hendrik Greving <hendrik dot greving dot intel at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 12 Nov 2013 06:56:45 +1000
- Subject: Re: Vectorizer/alignment
- Authentication-results: sourceware.org; auth=none
- References: <CANc4vhqiMCbkHHbKjY-tPmvi7iU4wXP4Jf_4S83jGTBJTCCi3Q at mail dot gmail dot com> <3a0cd1a6-76c9-4539-9830-8ddbf5405db3 at email dot android dot com> <CANc4vhobNfNQkm1HdFjL5c1tUnxOiNyumFG5XUCb71LRxBdU5g at mail dot gmail dot com> <CAFiYyc0G5vCtQp9Zy-xUyfeK6475FrVn++yacW1kB_v5H+nTjQ at mail dot gmail dot com> <20131111113922 dot GW27813 at tucnak dot zalov dot cz> <CAFiYyc0TtYQUaaYCkVYKMbMu3o7XrG_Sd8HbwbNGxpto4-wcgw at mail dot gmail dot com> <20131111133926 dot GX27813 at tucnak dot zalov dot cz> <CAFiYyc0AHfKdmOT5ovL5TgvPyF0-H2qHroFwLWCGaeCxB3X4OQ at mail dot gmail dot com>
On 11/11/2013 11:57 PM, Richard Biener wrote:
> On Mon, Nov 11, 2013 at 2:39 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote:
>>> On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>>>> On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote:
>>>>> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving
>>>>> <hendrik.greving.intel@gmail.com> wrote:
>>>>>> That didn't do it. What was the rationale w.r.t. to the relation
>>>>>> between the vectorized sequenced and/or the alignment (I think these
>>>>>> things are actually 2 separate things..) and the common block?!
>>>>>
>>>>> We cannot adjust the alignment of a common block as we don't know
>>>>> which common block the linker will pick in the end. We can (and do)
>>>>> adjust the alignment of global variables though. And C++ defaults
>>>>> to -fno-common.
>>>>>
>>>>> In general when asking optimization questions it helps to provide
>>>>> a testcase that can be compiled - otherwise you just provoke
>>>>> random guesses (like mine) ;)
>>>>
>>>> Well, we had the discussion about turning -fno-common by default for C as
>>>> well, I think it wouldn't hurt and let people use -fcommon if they need it.
>>>
>>> Yeah, so ... shall we just do it? Maybe just for a selected set of
>>> targets (based on OS?)?
>>
>> I vote for it. Perhaps with the exception when the variables are also weak,
>> this worst case results in a link time failure which is easily fixable by
>> adding -fcommon where really required, and in the usual case (dynamic
>> linking) it is limited to the each package individually, if we document this
>> in porting_to.html, I think changing the default is fine.
>>
>> But I guess it would be nice to hear more voices.
>
> Most fallout will be from headers that fail to declare variables
> as 'extern' (IIRC SPEC CPU 2000 has tons of that). It also
> hides bugs where one unit has 'int x' and one 'float x' (SPEC CPU 2006,
> LTO diagnoses this).
It's for reasons like this that I'd not be especially comfortable
changing the default of -fcommon for c89 (or gnu89, our default).
I think we'd be ok changing the default for c99+, as that implies
a certain "recentness" about the program under compilation, which
to me implies they ought to know better.
>
> I suppose targets without .bss section support should not switch
> (that is, targets not defining BSS_SECTION_ASM_OP or
> ASM_OUTPUT_ALIGNED_BSS).
Good point. I don't expect that we have many of those left, but
if any do still exist...
r~