There are 8 functions dealing with LLVMAttribute in include/llvm-c/Core.h.<div>Do you suggest to add 8 more functions that will deal with uint64_t? </div><div>Like this? </div><div><br></div><div>void LLVMAddFunctionAttr(LLVMValueRef Fn, LLVMAttribute PA);   </div>
<div>void LLVMAddFunctionAttr64(LLVMValueRef Fn, uint64_t PA);</div><div><br></div><div>--kcc </div><div><br><br><div class="gmail_quote">On Mon, Jan 23, 2012 at 1:40 PM, Paul Robinson <span dir="ltr"><<a href="mailto:pogo.work@gmail.com">pogo.work@gmail.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="HOEnZb"><div class="h5">On Mon, Jan 23, 2012 at 12:05 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>

><br>
><br>
> On Mon, Jan 23, 2012 at 12:01 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Mon, Jan 23, 2012 at 11:02 AM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>><br>
>> wrote:<br>
>> > My previous change in include/llvm-c/Core.h that introduced 64-bit<br>
>> > Attributes (r148553) caused a warning<br>
>> > while building with MSVC. <a href="http://llvm.org/bugs/show_bug.cgi?id=11828" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=11828</a><br>
>> > The following patch fixes the problem (use "static const uint64_t"<br>
>> > instead<br>
>> > of enum).<br>
>> > Ok to commit?<br>
>> ><br>
>> > --kcc<br>
>> ><br>
>> > Index: include/llvm-c/Core.h<br>
>> > ===================================================================<br>
>> > --- include/llvm-c/Core.h  (revision 148708)<br>
>> > +++ include/llvm-c/Core.h  (working copy)<br>
>> > @@ -92,7 +92,7 @@<br>
>> >  /** Used to get the users and usees of a Value. See the llvm::Use<br>
>> > class. */<br>
>> >  typedef struct LLVMOpaqueUse *LLVMUseRef;<br>
>> ><br>
>> > -typedef enum {<br>
>> > +static const uint64_t<br>
>> >      LLVMZExtAttribute       = 1<<0,<br>
>> >      LLVMSExtAttribute       = 1<<1,<br>
>> >      LLVMNoReturnAttribute   = 1<<2,<br>
>> > @@ -119,8 +119,8 @@<br>
>> >      LLVMReturnsTwice = 1 << 29,<br>
>> >      LLVMUWTable = 1 << 30,<br>
>> >      LLVMNonLazyBind = 1U << 31,<br>
>> > -    LLVMAddressSafety = 1ULL << 32<br>
>> > -} LLVMAttribute;<br>
>> > +    LLVMAddressSafety = 1ULL << 32;<br>
>> > +typedef uint64_t LLVMAttribute;<br>
>> ><br>
>> >  typedef enum {<br>
>> >    /* Terminator Instructions */<br>
>><br>
>> Hmm... actually, I'm not sure this is okay; it's a<br>
>> non-binary-compatible change to the C API.<br>
><br>
><br>
> Any other suggestion?<br>
> It's not easy to keep compatibility once the new (beyond 32-bits) attributes<br>
> start getting used.<br>
> Maybe add "enum LLVMAttribute2" for attributes in bits 33-64?<br>
><br>
> --kcc<br>
><br>
>><br>
>><br>
>> -Eli<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
<br>
I've run into this kind of problem before.<br>
<br>
A separate enum for attributes >= 32 is a royal pain.<br>
It's an implementation artifact that has no relevance to the<br>
semantics of the attributes.<br>
You'd need to add a new API to take the upper attributes,<br>
and the caller has to remember (or look up, every time)<br>
which attributes go with which enum.  :-P<br>
<br>
Defining a new 64-bit type that understands all attributes<br>
is better, as all attributes can be handled the same way.<br>
You still need a new API, but the caller does not have to<br>
understand some arbitrary split between two different enums.<br>
<br>
Pogo<br>
</blockquote></div><br></div>