This is the mail archive of the
mailing list for the GCC project.
Re: [lto] set alias info, poorly
Richard Guenther wrote:
> On Dec 10, 2007 9:01 PM, Kenneth Zadeck <firstname.lastname@example.org> 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
> 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
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.