<br><br><div class="gmail_quote">On Tue, Feb 7, 2012 at 11:42 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Jan 20, 2012, at 9:56 AM, Kostya Serebryany wrote:<br>
> Author: kcc<br>
> Date: Fri Jan 20 11:56:17 2012<br>
> New Revision: 148553<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=148553&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=148553&view=rev</a><br>
> Log:<br>
> Extend Attributes to 64 bits<br>
><br>
> Problem: LLVM needs more function attributes than currently available (32 bits).<br>
> One such proposed attribute is "address_safety", which shows that a function is being checked for address safety (by AddressSanitizer, SAFECode, etc).<br>
><br>
> Solution:<br>
> - extend the Attributes from 32 bits to 64-bits<br>
> - wrap the object into a class so that unsigned is never erroneously used instead<br>
> - change "unsigned" to "Attributes" throughout the code, including one place in clang.<br>
> - the class has no "operator uint64 ()", but it has "uint64_t Raw() " to support packing/unpacking.<br>
> - the class has "safe operator bool()" to support the common idiom:  if (Attributes attr = getAttrs()) useAttrs(attr);<br>
> - The CTOR from uint64_t is marked explicit, so I had to add a few explicit CTOR calls<br>
> - Add the new attribute "address_safety". Doing it in the same commit to check that attributes beyond first 32 bits actually work.<br>
> - Some of the functions from the Attribute namespace are worth moving inside the class, but I'd prefer to have it as a separate commit.<br>
><br>
> Tested:<br>
> "make check" on Linux (32-bit and 64-bit) and Mac (10.6)<br>
> built/run spec CPU 2006 on Linux with clang -O2.<br>
<br>
</div>Using a class here is introducing global initializers into every translation unit that includes llvm/Attributes.h.  Those initializers are optimized out at -O1 (by clang, at least), but it's still bad practice. </blockquote>
<div><br></div><div>Why?</div><div>This code looks clean and effective (with >=O1). </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If you remove all the constructors from the class, you can use list-initialization instead, which (in this case) is essentially guaranteed to not require a global initializer;  the only other alternative (given MSVC's limitations) </blockquote>
<div><br></div><div>What are these limitations? </div><div>We can probably come up with something like a proxy class to initialize the Attribute constans, not sure if it's worth doing so.</div><div>What are your suggestions? </div>
<div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">is to give up on type-safety and use a typedef for uint64_t, which I think is the easiest answer, if also the most dissatisfying.<br>

<span class="HOEnZb"><font color="#888888"><br>
John.<br>
</font></span></blockquote></div><br>