This is the mail archive of the 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: [lto] set alias info, poorly

Richard Guenther wrote:
> On Dec 10, 2007 9:01 PM, Kenneth Zadeck <> wrote:
>> Toon Moene wrote:
>>> Kenneth Zadeck wrote:
>>>> If you want to ask a question about two types, the first part of
>>>> that check will to see if the types come from the same front end.  If
>>>> they do, then this issue can be resolved by asking some language
>>>> dependent code that will be located in the middle end of the compiler.
>>> Well, that will mean that it'll be a fascinating piece of "language
>>> dependent code [...] located in the middle end of the compiler".
>>> The Fortran rules are basically:  If you don't *tell* the compiler
>>> (hence the front end) that two items alias, they don't.
>>> I think this means that LTO *with* Fortran-sensible alias analysis
>>> will only work if the Fortran front end actually determines alias
>>> equivalence sets and passes that down to the middle end, which then
>>> (in this magically "language dependent code") has to do something
>>> intelligent with it ...
>> And then we will need to "merge" that info as we bring in the code for
>> other fortran modules.
>> i am not happy about going down this path, but the loss of that info is
>> not a good choice either.
>> Consider the java case where two pointers cannot alias unless the type
>> of one pointer is derived from the other.  This means that most pointers
>> do not alias rather than the c/c++ case where most pointers can possibly
>> alias.
> The only maintainable way I see is to define middle-end rules (based on
> structural analysis) that are a conservative approximation of the union of
> the rules of all supported languages.  Or punt with TBAA completely for
> LTO.
> Richard.
i think that you make a mistake to assume that just because type based
aliasing is mostly useless in c/c++, that it is useless in every
language.  it is not. I believe that giving up on this will be a mistake.


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