<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
</span>I don't think this fully solves the problem -- you'll also need to fix<br>
getMostGenericTBAA.  That is, even if you implement the above scheme,<br>
say you started out with:<br>
<span class="gmail-"><br>
union U {<br>
  int i;<br>
  float f;<br>
</span>};<br>
<br>
float f(union U *u, int *ii, float *ff, bool c) {<br>
  if (c) {<br>
    *ii = 10;<br>
    *ff = 10.0;<br>
  } else {<br>
    u->i = 10;    // S0<br>
    u->f = 10.0;  // S1<br>
  }<br>
  return u->f;<br>
}<br>
<br>
(I presume you're trying to avoid reordering S0 and S1?)<br>
<br>
SimplifyCFG or some other such pass may transform f to:<br>
<br>
float f(union U *u, int *ii, float *ff, bool c) {<br>
  int *iptr = c ? ii : &(u->i);<br>
  int *fptr = c ? ff : &(u->f);<br>
  *iptr = 10;     // S2<br>
  *fptr = 10.0;   // S3<br>
  return u->f;<br>
}<br>
<br>
then getMostGenericTBAA will infer scalar "int" TBAA for S2 and scalar<br>
"float" TBAA for S3, which will be NoAlias and allow the reordering<br>
you were trying to avoid.<br></blockquote><div><br></div><div>FWIW, i have to read this in detail, but a few things pop out at me.</div><div><br>1. We would like to live in a world where we don't depend on TBAA overriding BasicAA to get correct answers.  We do now, but don't want to.<br>Hopefully this proposal does not make that impossible.</div><div><br></div><div>2.  Literally the only way that GCC ends up getting this right is two fold:</div><div>It only guarantees things about direct access through union.</div><div>If you take the address of the union member (like the transform above), it knows it will get a wrong answer.</div><div>So what it does is it finds the type it has to stop at (here, the union) to keep the TBAA set the same, and makes the transform end there.</div><div>So the above would not occur.</div><div><br></div><div><br></div><div>3. A suggestion that TBAA follow all possible paths seems .. very slow.</div><div><br></div><div>4. "<span style="font-family:sans-serif">The main motivation for this is functional correctness of code using unions".  I believe you mean "with tbaa and strict-aliasing on".</span></div><div><span style="font-family:sans-serif">If not,functional correctness for unions should not be in any way related to requiring TBAA.</span></div><div><br></div><div>5. Unions are among the worst area of the standard in terms of "nobody has really thought super-hard about the interaction of aliasing and unions in a way that is coherent".<br></div><div>So when you say things like 'necessary for functional correctness of unions', just note that this is pretty much wrong.  You probably mean "necessary for a reasonable interpretation" or something.</div><div><br></div><div>Because we would be *functionally correct* by the standard by destroying the program  if you ever read the member you didn't set :)</div><div><br></div><div><br></div><div><br></div></div></div></div>