I love it in principle. As you get closer to finalizing the syntax, etc. I might have some more detailed comments, but nothing really substantive.<div class="gmail_extra"><br></div><div class="gmail_extra">Minor API comment as that seems more immediate:<br>
<br><div class="gmail_quote">On Wed, Sep 19, 2012 at 3:25 PM, Bill Wendling <span dir="ltr"><<a href="mailto:wendling@apple.com" target="_blank" class="cremed">wendling@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
An example syntax could be:<br>
<br>
// Building an Attribute<br>
<br>
Attributes A;<br>
A.addAlignAttr(4)<br>
 .addNoUnwindAttr()<br>
 .addStackProtectorAttr()<br>
 .addUnwindTableAttr()<br>
 .addReadNoneAttr();<br></blockquote><div><br></div><div>Personally, I would prefer to make the Attributes class be immutable, and the building happen in a helper. One possible interface would end up looking like:</div><div>
<br></div><div><font face="courier new, monospace">Attributes Base = ...;</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Attributes A = Attributes::Builder(Base).addNoUnwind()</font></div>
<div><div><font face="courier new, monospace">                                        .addStackProtector()</font></div></div><div><div><font face="courier new, monospace">                                        .addAlign(4);</font></div>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
// Querying an Attribute<br>
<br>
if (!A.hasStackProtector() || A.hasAlign(4))<br>
   ...<br>
<br>
The Attributes class will be expanded in the future to support code generation<br>
and target-specific options. But it won't require a massive rewrite of the<br>
compiler to do so.<br>
<br>
The bit-wise operations on the Attributes class will need to be removed. This is<br>
because the internals of the Attributes class may no longer be a bitfield.<br>
<br>
Summary<br>
=======<br>
<br>
The Attributes class is going to change in some seriously fundamental ways, but<br>
it will result in a much more extensible and flexible class. The changes to the<br>
code base will be mostly mechanical in nature. The transition is easily<br>
serialized, so any problems can be caught early on.<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" class="cremed">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank" class="cremed">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>