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 >> alignment >> 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 > case? > > 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. Richard. > Ian