<div class="gmail_quote">On Thu, Jan 19, 2012 at 9:56 AM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote">On Thu, Jan 19, 2012 at 1:18 AM, Anton Korobeynikov <span dir="ltr"><<a href="mailto:anton@korobeynikov.info" target="_blank">anton@korobeynikov.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi Kostya,<br>
<div><br>
<br>
> The patches are attached, the llvm patch is also published<br>
> here: <a href="http://codereview.appspot.com/5544058/" target="_blank">http://codereview.appspot.com/5544058/</a><br>
</div>What is the performance impact of this?<br></blockquote><div><br></div><div>Good point (I assume you mean compile-time performance, not the performance of compiled programs).</div><div>I've verified that the compile-time did not change by building 403.gcc and 483.xalancbmk with the original and modified clang with -O1. </div>
</div></blockquote><div><br></div><div>Out of curiosity did you check the compile-time performance for 64-bit clang/llvm, 32-bit clang/llvm, or both?  I would imagine that extending attributes to 64-bit would have negligible impact for a 64-bit compiler binary but potentially greater impact for a 32-bit one as they would no longer fit in a single register.</div>
<div></div></div><br><div>Cheers,</div><div>Kaelyn</div>