<div>Here is the preliminary patch. </div><div>It wraps the uint64_t bitmask into a class, but still provides "uint64_t Raw();"</div><div>(mostly for serialization/deserialization methods).</div><div><br></div><div>
Before the full review, I'd like to get a general feedback: is this how we want this to be done? </div><div><br><div>The patch passes 'make check' on one platform, but needs more testing. </div><div>I also want to add at least one attribute after the 32-nd bit to verify that it works. </div>
<div><br></div><div>It may also make sense to move some functions (e.g. constructAlignmentFromInt) inside the class definition, </div><div>but I'd prefer to have it as a separate commit. </div><div><br></div><div>--kcc</div>
<div><div><br></div><div><br><br><div class="gmail_quote">On Thu, Jan 12, 2012 at 1:25 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@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"><br>
On Jan 12, 2012, at 1:03 PM, Anton Korobeynikov wrote:<br>
<br>
> Hi Kostya,<br>
><br>
>> How about implementing Attributes as a class with 64-bit integer under the<br>
>> hood?<br>
>> This will protect us from erroneous casts to/from 32-bit unsigned.<br>
>> I have a change half-done but I want to know llvmdev's opinion before<br>
>> proceeding.<br>
> Yes, this sounds like a proper approach. Which will allow us to switch<br>
> over other implementation of attributes, if necessary.<br>
<br>
</div>+1  :)<br>
<span class="HOEnZb"><font color="#888888"><br>
-Chris<br>
</font></span></blockquote></div><br></div></div></div>