<br><br><div class="gmail_quote">On Tue, Jan 10, 2012 at 12:45 AM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr">baldrick@free.fr</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><div class="h5"><br>
> Today, llvm/Attributes.h defines 'Attributes' as 'unsigned'.<br>
> This bit vector is fully packed, and I am probably not the only one who wants to<br>
> add bits to it.<br>
> Is there a strong reason not to define Attributes as uint64_t?<br>
> At first glance this seems doable, and the IR reader/writer will not need to be<br>
> changed at all (or at least, not significantly).<br>
<br>
</div></div>probably attributes should become a (pointer to) a more complicated data<br>
structure.  </blockquote><div><br></div><div>that would be a bigger change... </div><div>Does anyone else feel such need? </div><div>(I need just one extra bit for AddressSanitizer/SAFEcode :))</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For example, I would like to get rid of the zext/sext parameter<br>
attributes and replace with "z/sexted_from(type)" where type is an arbitrary<br>
integer type.  </blockquote><div><br></div><div>You mean, other than i8/i16/i32/i64?</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">
This will never fit into 64 bits.  Maybe now is the time to<br>
think of a more powerful representation for attributes.<br>
<br>
Ciao, Duncan.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br>