[LLVMdev] [RFC] Overhauling Attributes

Chandler Carruth chandlerc at google.com
Wed Sep 19 16:09:21 PDT 2012

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.

Minor API comment as that seems more immediate:

On Wed, Sep 19, 2012 at 3:25 PM, Bill Wendling <wendling at apple.com> wrote:

> An example syntax could be:
> // Building an Attribute
> Attributes A;
> A.addAlignAttr(4)
>  .addNoUnwindAttr()
>  .addStackProtectorAttr()
>  .addUnwindTableAttr()
>  .addReadNoneAttr();

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:

Attributes Base = ...;

Attributes A = Attributes::Builder(Base).addNoUnwind()

> // Querying an Attribute
> if (!A.hasStackProtector() || A.hasAlign(4))
>    ...
> The Attributes class will be expanded in the future to support code
> generation
> and target-specific options. But it won't require a massive rewrite of the
> compiler to do so.
> The bit-wise operations on the Attributes class will need to be removed.
> This is
> because the internals of the Attributes class may no longer be a bitfield.
> Summary
> =======
> The Attributes class is going to change in some seriously fundamental
> ways, but
> it will result in a much more extensible and flexible class. The changes
> to the
> code base will be mostly mechanical in nature. The transition is easily
> serialized, so any problems can be caught early on.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120919/50378706/attachment.html>

More information about the llvm-dev mailing list