[Bug tree-optimization/114959] incorrect TBAA for drived types involving function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959 --- Comment #4 from Jan Hubicka --- > > I think function types are somewhat special in that they do not denote > objects in the classical sense. They are also most complex and probably > target-dependent to handle. > > Note there's LTO where we glob all pointers to a single equivalence class > because of Fortran where C_PTR inter-operates with all pointer types. But We special case void * to alias with all other pointer types and look through pointers in alias.cc, so accesses through pointers are not necessarily fully globbed. I plan to look into unglobbing pointers when Fortran C_PTR can not clash since this is relatively important piece of TBAA information. Honza
[Bug tree-optimization/114959] incorrect TBAA for drived types involving function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959 --- Comment #3 from Richard Biener --- (In reply to Martin Uecker from comment #2) > The GCC FE has all the necessary logic to compute type compatibility and > this could easily be adapted to compute equivalence classes and then set a > TYPE_CANONICAL. All function types in the same class would get the same > TYPE_CANONICAL even if a little bit different, i.e. return pointers to > compatible but slightly different array types. I think function arguments > we need to ignore completely, because > > T (*f)(); > > is compatible with all pointers to functions with the same return type. > (this is gone in C23 though) Or we special case such functions. > > What is unclear to me whether function types are the only remaining issue or > whether this should then be done for all types (pointers, arrays, etc)? I think function types are somewhat special in that they do not denote objects in the classical sense. They are also most complex and probably target-dependent to handle. Note there's LTO where we glob all pointers to a single equivalence class because of Fortran where C_PTR inter-operates with all pointer types. But LTO would compute FUNCTION_TYPE TYPE_CANONICAL in a less conservative way than required for the above rule for C. That said, we do not stream TYPE_CANONICAL into the LTO IL but instead attempt to recompute it (for the sole purpose of TBAA) in a way compatible with all language frontends (without considering possible knowledge of frontends involved in the link).
[Bug tree-optimization/114959] incorrect TBAA for drived types involving function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959 --- Comment #2 from Martin Uecker --- The GCC FE has all the necessary logic to compute type compatibility and this could easily be adapted to compute equivalence classes and then set a TYPE_CANONICAL. All function types in the same class would get the same TYPE_CANONICAL even if a little bit different, i.e. return pointers to compatible but slightly different array types. I think function arguments we need to ignore completely, because T (*f)(); is compatible with all pointers to functions with the same return type. (this is gone in C23 though) Or we special case such functions. What is unclear to me whether function types are the only remaining issue or whether this should then be done for all types (pointers, arrays, etc)?
[Bug tree-optimization/114959] incorrect TBAA for drived types involving function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959 Richard Biener changed: What|Removed |Added Version|unknown |14.0 Keywords||wrong-code CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener --- alias.c does /* See if the language has special handling for this type. */ set = lang_hooks.get_alias_set (t); if (set != -1) return set; /* There are no objects of FUNCTION_TYPE, so there's no point in using up an alias set for them. (There are, of course, pointers and references to functions, but that's different.) */ else if (TREE_CODE (t) == FUNCTION_TYPE || TREE_CODE (t) == METHOD_TYPE) set = 0; but when handling pointer-to-function we simply create a new alias-set for each distinct (according to TYPE_CANONICAL (TYPE_MAIN_VARIANT ( pointed-to type. It's going to be difficult to canonicalize return and argument types here, so the answer is probably tree.cc:maybe_canonicalize_argtypes and thus reflecting this in the TYPE_CANONICAL of the function type. Note this is also how we handle pointer to structure types, but as structures are real objects those already have TYPE_CANONICAL set up appropriately. So I wonder whether the C frontend doesn't need to do the same for FUNCTION_TYPEs rather than putting the burden on the middle-end here?
