<div dir="ltr">I don't have great data, but if you have any relevant benchmarks of your own you can try them -f{no-}strict-aliasing to compare their performance</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 18, 2021 at 11:11 AM Victor Yodaiken <<a href="mailto:victor.yodaiken@gmail.com">victor.yodaiken@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Exactly.  The C Standards committee has justified complex rules for programmers and compiler writers ( which seem to often cause programmers to yell at compiler writers) on the basis of optimization gains - but without much documentation. I am looking for information on whether those are significant enough to justify the tradeoff. <div><br></div><div>thanks</div><div>vy</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 18, 2021 at 1:03 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 18, 2021 at 10:13 AM Richard Kenner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I would think that in a language like C, the role of the optimizer<br>
> should be to do optimizations that are difficult or impossible or<br>
> time consuming for the programmer.<br>
<br>
That's a philosphical question.  Keep in mind that very few<br>
programmers nowadays, even in C, have a good idea of the underlying<br>
machine model (or even the fact that there *is* such a model), so they<br>
don't really even know what to do.  Also, think of macro expansion and<br>
such.  And maintenance costs over time if you add all of the<br>
"clutter".  I would argue against that view.<br>
<br>
> My concern is that TBAA has a trade-off in terms of the complexity of the<br>
> language for the programmer<br>
<br>
I don't understand.  TBAA implements the rules of the programming language<br>
with respect to aliasing.  It doesn't change the language in any way, so <br>
I don't see how it can increase the complexity for the programmer.<br>
<br>
Perhaps you're arguing that anti-aliasing rules in languages aren't<br>
worth the complexity, but that's a different issue and one that language<br>
design groups look at, not compiler writers.<br></blockquote><div><br>There's a lot of overlap, and it's probably good for language design groups to be talking to compiler writers (as in this thread) to understand what really matters in practice - if the answer was "there aren't significant benefits to using TBAA" then maybe that'd inform language design groups to remove such requirements from their specifications, etc. I expect that's where Victor is coming at this from - to understand/gather implementation experience to inform language design.<br><br>Or potentially to inform compiler implementations - violating TBAA is UB, so it's valid for an implementation to define that behavior (eg: could change the default to be -fno-strict-aliasing).</div></div></div>
</blockquote></div>
</blockquote></div>