On Fri, Apr 6, 2012 at 12:15 AM, Ian Lance Taylor <i...@google.com> wrote:
> Richard Guenther <richard.guent...@gmail.com> writes:
>> On Thu, Apr 5, 2012 at 6:22 AM, Mike Stump <mikest...@comcast.net> wrote:
>>> On Apr 4, 2012, at 7:56 PM, William J. Schmidt wrote:
>>>> There seems to be tacit agreement that the vector tests should use
>>>> -fno-common on all targets to avoid the recent spate of failures (see
>>>> discussion in 52571 and 52603).
>>>> OK for trunk?
>>> Ok. Any other solution I think will be real work and we shouldn't loose
>>> the testing between now and then by not having the test cases working.
>> Ian, you are the "source" of all of these problems. While I did not notice
>> any degradations in SPEC (on x86) with handling commons "correctly"
>> now, the fact
>> that our testsuite needs -fno-common to make things vectorizable shows
>> that users might be impacted negatively by this, which is only a real problem
>> in corner cases. Why can the link editor not promote the definitions
>> when merging with a common with bigger alignment?
> The defined symbol will be embedded in a data section along with other
> defined data symbols, at some offset O from the start of the section.
> The data section will have a required alignment A. It is entirely
> possible that there is no way to honor A and also ensure that A+O is
> aligned as requested by the common symbol.
> This whole issue only applies to vectorization involving global symbols
> defined with no initializer in C, when vectorization requires an
> alignment greater than that implied by the type of the symbol. It does
> not affect function arguments or local variables. It does not affect
> C++. Is vectorization of uninitialized global symbols really a common
> Another approach we could use is to say that when the vectorizer wants
> to increase the alignment of a common symbol, it would force the symbol
> to be defined rather than common. That would be safe, as it would lead
> to a multiple-definition error at link time in cases where it would be
> unsafe. I would be fine with making the compiler work that way for C,
> although of course there would have to be an option to disable it.
That would work fine at least with LTO - though I'm not sure the linker-plugin
gives enough feedback that a common is not overridden by an external
definition. Maybe it would be a good idea to promote all commons to
definitions with LTO (where possible, of course).
> I don't know enough about Fortran to know whether the same issues arise
> there. Perhaps in Fortran a common symbol is always a common symbol and
> can never be a defined symbol. If that is the case then for Fortran I
> think it would be safe to change the alignment of the common symbol. Of
> course we would need to have some way to indicate that in the
> middle-end--DECL_ALWAYS_COMMON or something.
I don't know either. OTOH commons are records, so the vectorizer cannot
change alignment of a common sub-variable - so in this case it would be
better if the frontend would align the common to BIGGEST_ALIGNMENT or so.