Re: [lto] set alias info, poorly

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Jakub Jelinek wrote:
> On Fri, Dec 07, 2007 at 11:47:46AM +0100, Richard Guenther wrote:
>   
>> On Dec 6, 2007 11:29 PM, Nathan Froyd <froydnj@codesourcery.com> wrote:
>>     
>>> First, the good news about this patch: it fixes a few failing testcases.
>>>
>>> The bad news is that it does it with a very heavy hammer.  We say that
>>> every type can alias every other type.  Obviously this wreaks havoc with
>>> all the clever alias analysis that has gone into GCC over the years.
>>>
>>> There are better, cleverer, more involved ways that you could fix this.
>>> But this demonstrably works right now.  Ideas on what to do in the
>>> future welcome.
>>>       
>> I believe we have to write out the alias sets and the conflict map and at the
>> point we combine types of different translation units we have to merge the
>> alias sets and conflict maps properly.
>>     
>
> Yeah, basically write LTO's own get_alias_set langhook, which will act as
> the C one for C CUs, as C++ for C++ CUs, as Fortran for Fortran CUs etc. and
> additionally define what kind of aliasing is/is not possible for types
> passed from one language to a different one.
>
> 	Jakub
>   
What Nathan did not say was that he was doing this at the direction of
Diego, Mark and myself.
We had a conference call to discuss how to deal with this issue, both in
the short term and the long term.  This was the short term solution and
all of us understood that this is not a particularly good short term
solution.

The longer term solution will be quite complex and is at this point not
well understood. 
Nathan's patch turns off the part of the alias analysis where the front
end gets to make the final decision if two types alias. 

My personal take on how to reimplement this langhook is that we will end
up tagging every type with an indication of which front end it came
from.  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. 

If the two types come from different front ends, then the question will
be resolved using a language dependent, and therefore relatively
pessimistic, structural test.  I do not like doing this, but the
aliasing rules for different languages are quite different and cost of
just ignoring them is quite high. 

I know that different people on that call have different takes on this
than mine.  At the very least this is something that requires a lot of
discussion by not just us, but the entire community as well the
resources to implement what is likely to be a lot of work.  We certainly
did not have a simple solution that did better. Writing out the alias
sets and then trying to merge them when the input comes from different
languages seems to me to be a bad way to go. 

However, the view of the people on the call was that we had to go for
correctness and coverage right now so that the community had something
stable to play with.

Kenny