This is the mail archive of the gcc-patches@gcc.gnu.org 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: Cleanup and improve canonical type construction in LTO


On Thu, 21 May 2015, Jan Hubicka wrote:

> > On Wed, 20 May 2015, Jan Hubicka wrote:
> > >  Code quality does not seem to be affected too much,
> > > which I suppose is partly thanks to that tree-ssa-alias.c pointer hack.  My
> > > main point was to cleanup the hack about comparing only TYPE_CODE of
> > > pointer_type and make more sense of the whole machinery.
> > 
> > Well, TYPE_CODE was supposed to mimic what you do explicitely now.  I'm
> > curious when the recursion determines incompatibility but the TYPE_CODE
> > is equal.  What cases are those?
> > 
> > How do you handle void * vs. any other pointer type?  For cross-language
> > LTO I think we need to treat those compatible.  At least void * is
> > equal to struct Foo * (with incomplete Foo).
> 
> Well, if you would force this rule for canonical type calculation, then by
> transitivity we could make no difference between pointers at all.

That's kind of my point - and it was the reason to add that
get_alias_set () "hack" globbing all pointer-types.  I think it was
inspired by actual code in the wild (mostly C code though...) that
expects to be able to store all pointer types to *(void *)x, thus
void * being a valid abstraction for all pointer types.  At the
point of introducing the hack I decided to not allow that by
assigning alias-set zero to void * pointers (well, all pointers to
incomplete types) but to glob all pointer types instead.

> I think the only way to enforce such non-transitive rules is via alias sets.
> Just like alias set 0 alias with everything without really degenerating every
> canonical type to a single type.

But alias-sets also obey transitivity rules, no?  Or you mean introducing
another "alias-set zero" globbing all pointers and using that for
pointers to incomplete types?  (what about void **?  The same 
"abstraction" argument applies to that if I want to store a X **)

In the end I like the simplicity of the current approach very much
(likewise using element alias-sets for vector/array type 
alias-sets)

> > > Bootstrapped/regtested x86_64-linux with LTO and also tested on Firefox. ppc64
> > > build in progress. OK?
> > 
> > Not looking at the patch - please split it up into small pieces so we
> > can bisect in case of problems.  This is a tricky area, esp. considering
> > cross-language LTO.  We might be not conservative enough with
> > canonical types (given the get_alias_set pointer handling).
> 
> Yep, i looked into the pointer handling hack. 
> 
> Thanks for looking into this.  I know it is a tricky area.

Indeed.

Richard.


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