https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #51 from James Kuyper Jr. <jameskuyper at alumni dot caltech.edu> --- (In reply to Andrew Haley from comment #49) > (In reply to James Kuyper Jr. from comment #46) > > (In reply to Andrew Haley from comment #42) > > ... > > > In order to use type-based alias analysis in any LTO framework it's > > > necessary to save type information, and this is just more type > > > information. ... > > > > > ... The question is, I suppose, how to handle the scopes of > > > union declarations. I'd just treat them as being global, which in > > > practice isn't unrealistic because such declarations are in header > > > files in global scope and shared anyway. > > > > Why not use the actual scope of the completed union declaration, > > which is what the relevant rule refers to? > > The principle of type-based alias analysis is that all you know about > two types is their types, not the location of any code that uses them. > There are no scopes. The oracle, given only the types, has to say > whether they alias or not, regardless of where those types are used in > a program. The location isn't an input to the oracle. > > Bear in mind that inlining and other kinds of code motion happen, and > code is often evaluated "outside" the scopes in which it was written > and in a completely different order. That's all perfectly normal > optimization. > > Besides, when the alias oracle is consulted, all that scope stuff has > gone. It's only relevant to the front end. I was only pointing out that implementing this special guarantee where it applies, and only where it applies, requires keeping information that must already have been collected. If the current design discards that information before performing the relevant optimizations, I can understand that this would require a significant re-design - but the re-design takes the form of saving information already collected, not of collecting additional information. > > > So, if any union types with a common initial sequence are declared > > > anywhere in a program, then their member types alias. > > > > As I understand it, the visibility rule was added specifically for > > the purpose of NOT requiring that the entire program be covered by > > this exception. > > I don't think so. As I read it, it was a way of declaring to the > compiler that they types are intended to alias. By "the visibility rule", I mean, very specifically, the phrase "anywhere that a declaration of the completed type of the union is visible". If the intent had been to disable aliasing throughout the entire program, that intent could have been expressed by simply removing those words entirely; if there was any doubt that people would understand the absence of those words correctly, then they could have been replaced with the phrase "anywhere, regardless of whether or not the completed type of the union was visible". I don't see any plausible reason for the committee to write "anywhere that a declaration of the completed type of the union is visible", unless that phrase was intended to restrict applicability of the special guarantee. > > Knowledgeable people writing code intended to take advantage of this > > feature of C are likely to carefully place completed declarations of > > the union's type so they disable those optimizations only where they > > need to be disabled, and to minimize the amount of code where this > > exception would unnecessarily disable useful optimizations. > > Perhaps so, yes, but in practice it'd be pretty hard to do that. > Functions can only be defined in the other scope, and there's no way > to undefine a union type. True, but failing to define the union type is quite trivial. If I were writing code that used both struct types, but not the union type, and did nothing that relied upon the fact that they can alias each other, I would simply not #include the header that defines the completed union type, #including only the header that defines the struct types. If I needed to put such code in the same translation unit as code which actually needs the union declaration, I would put the code that doesn't need it before the #include, and put the code that does need it after the #include - but that would probably be more trouble than it's worth.
