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.
