> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Hi,
> > this is a variant of patch that globs also the rest of integer types.
> > Note that we will still get false warnings out of lto-symtab when the
> > values are not wrapped up in structures. This is because lto-symtab
> > uses types_compatible_p that in turn uses useless_type_conversion and
> > that one needs to honor signedness.
> >
> > I suppose we need a way to test representation compatibility and TBAA
> > compatiblity. I will give it a more tought how to reorganize the code.
> > Basically we need
>
> representation compatibility is TYPE_CANONICAL equivalence, TBAA
> compatibility is get_alias_set equivalence.
>
> So you have to be careful when mangling TYPE_CANONICAL according to
> get_alias_set and make sure to only apply this (signedness for example)
> for aggregate type components.
Hmm, OK, so you think that
TYPE_CANONICAL (int) != TYPE_CANONICAL (unsigned int)
get_alias_set (TYPE_CANONICAL (int)) == get_alias_set (TYPE_CANONICAL (unsigned
int))
TYPE_CANOINCAL (struct {int}) == TYPE_CANONICAL (struct {unsgined int})
I suppose that makes sense because the actual fields of structure are not
really used for semantics (it depends on what FIELD_DECL we pull out).
I will build testcase and send a patch that will glob alias set of signed and
usigned types in LTO's own get_lias_set hook. I do not think we need to punish
aliasing of non-C languages (without LTO) by putting it all the way to alias.c.
As for structures, I have the following plan.
I plan to add computation of canonical types of pointers that will use
the canonical type of pointed-to type same was as non-LTO path does.
This however can not be propagated up to structure fields, since
pointer to complete structure must be compatile to pointer to incomplete
type. I suppose signed and unsgined values can be handled the same way.
We thus need to track in hash_canonical_type and gimple_types_compatible_p
if we are in a subtype of aggregate/array and if so, we don't want to use
TYPE_CANONICAL of the nested type and instead just recurse with more coarsce
equivalence defined.
Joseph, I may be wrong, but I believe that the cross-compilation-unit
representation compatibility (in C standard sense) is however not an
equivalence class, so it can't be fully represented by TYPE_CANOINICAL
equivalence.
We may want to warn about types not being compatible when compiling:
a.c:
struct b {int c;};
struct a {struct b *ptr;} var;
b.c:
struct b {long c;};
struct a {struct b *ptr;} var;
pointers are not required to be compatible with each other.
Or in more ugly way
int a[5]; as a structure field may be compatible with int a[b];
int a[b] is compatible with int a[10];
But in a[5] is not compatible with int a[10];
I am not sure if TYPE_CANONICAL of a structure with fixed size array
should match TYPE_CANONICAL of similarly looking structure with VLA.
>
> Can you please split out the string-flag change? It is approved.
OK, I will split it and commit it with the corresponding parts of the testcase
commented out. Thanks!
Honza
