<font size=2 face="sans-serif">Seems like the comments have stopped.  I'll
try to get a patch together.  Then we can continue the discussion
from there.  </font><br><br><font size=2 face="sans-serif">Hubert, as for the issue with the llvm
optimizations losing the TBAA information, it should be the responsibility
to make sure the aliasing is changed in the correct way.  One function
related to this has already been mentioned:  getMostGenericTBAA.</font><br><br><font size=2 face="sans-serif">Later,</font><br><font size=2 face="sans-serif">Steven Perron</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Hubert Tong <hubert.reinterpretcast@gmail.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">Steven Perron/Toronto/IBM@IBMCA</font><br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif">Daniel Berlin <dberlin@dberlin.org>,
llvm-dev <llvm-dev@lists.llvm.org>, Sanjoy Das <sanjoy@playingwithpointers.com></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">2017/02/15 07:44 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [llvm-dev]
RFC: Representing unions in TBAA</font><br><hr noshade><br><br><br><font size=3>On Tue, Feb 14, 2017 at 11:22 PM, Steven Perron <</font><a href=mailto:perrons@ca.ibm.com target=_blank><font size=3 color=blue><u>perrons@ca.ibm.com</u></font></a><font size=3>>
wrote:</font><br><font size=2 face="sans-serif">3) How should we handle a reference
directly through a union, and a reference that is not through the union?
 </font><font size=3><br></font><font size=2 face="sans-serif"><br>My solution was to look for each member of the union overlaps the given
offset, and see if any of those members aliased the other reference. 
If no member aliases the other reference, then the answer is no alias. 
Otherwise the answer is may alias.  The run time for this would be
proportional to  "distance to the root" * "number of
overlapping members".  This could be slow if there are unions
with many members or many unions of unions.</font><font size=3><br></font><font size=2 face="sans-serif"><br>Another option is to say that they do not alias.  This would mean
that all references to unions must be explicitly through the union.</font><br><font size=3>From what I gather from the thread so far, the access
through the union may be lost because of LLVM transformations. I am not
sure how, in the face of that, TBAA could indicate NoAlias safely (without
the risk of functional-correctness issues in correct programs) between
types which overlap within any union (within some portion of the program).<br></font><br><font size=3>As for the standards, it is definitely not true that all
references to unions must be explicitly through the union. However, if
you are trying to perform union-based type punning (under C11), then it
appears that it is intended that the read must be through the union.</font><br><font size=3> </font><br><font size=2 face="sans-serif">This would be the least restrictive
aliasing allowing the most optimization.  The implementation would
be simple.  I believe we make the parent of the TBAA node for the
union to be "omnipotent char".  This might be similar to
treating the union TBAA node more like a scalar node instead of a struct-path.
 Then the traversal of the TBAA nodes will be quick.  I'll have
to work this out a bit more, but, if this is good enough to meet the requirements
of the standard, I can try to think this through a little more.  I'll
need Hubert and Daniel to comment on that since I am no expert on the C
and C++ standards.</font><font size=3><br></font><font size=2 face="sans-serif"><br>The third option is to be pessimistic and say "may alias" all
of the time (conservatively correct), and rely on other alias analysis
to improve it.  This will have good compile time, but could hinder
optimization.  Personally I do not like this option.  Most of
the time it will not have a negative effect, but there will be a reasonable
number of programs where this will hurt optimization more that it needs
to.</font><br><br><br><BR>