<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 14, 2017 at 11:22 PM, Steven Perron <span dir="ltr"><<a href="mailto:perrons@ca.ibm.com" target="_blank">perrons@ca.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><br><br><font size="2" face="sans-serif">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><br><br><font size="2" face="sans-serif">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></blockquote><div>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><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><br><br><font size="2" face="sans-serif">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></blockquote></div><br></div></div>