[LLVMdev] [RFC] Overhauling Attributes

[Sean Silva]

If you make syntax changes please send patches to Pygments so that our
Sphinx docs remain pretty. Sphinx handles failures to lex in an
extremely non-graceful way; basically, it's policy is that if the code
it is asked to format as a particular language doesn't match it's
lexer, then it just gives up and leaves the entire block of code
unhighlighted :(

Even so much as using a keyword it doesn't recognize will cause it to
bail out immediately and leave the `.. code-block::` completely
unhighlighted. The relevant part of Pygments is
<https://bitbucket.org/birkenfeld/pygments-main/src/e97df81b39c7/pygments/lexers/asm.py#cl-193>;
it's pretty self-explanatory.

...aside... When I was attempting to Sphinxify LangRef, I actually ran
into a couple such instances where new keywords had been introduced. I
never finished that attempt since I eventually realized that LangRef
is 8000 lines of HTML: some kind of automated conversion is going to
be necessary (even with fancy vim macros and stuff my ETA was still
unreasonable).

--Sean Silva

On Wed, Sep 19, 2012 at 6:25 PM, Bill Wendling <wendling at apple.com> wrote:
>                          Overhauling Attributes
>
> Problem
> =======
>
> LTO needs a way to pass options through to different parts of the compiler. In
> particular, we need to pass code generation options to the back-end. The way we
> want to do this is via the LLVM Attributes class. In order to do that, we need
> to overhaul the Attributes class.
>
> The Attributes class right now isn't very extensible. After considering several
> different options, we decided it was best to extend the Attributes class to
> support *all* code generation options, even target-specific ones. It already
> supports some of them (like SSP), but it isn't very extensible because it is a
> fixed size bitfield. The size restriction also makes supporting options with
> values very difficult. As the number of options grow, we will soon have run out
> of space entirely.
>
> Target-Specific Attributes in IR
> ================================
>
> I propose that the target-specific attributes would be organized into groups.
> Those groups would then be referenced by the functions directly. Here is an
> example of what that could look like:
>
> attrgroup #1 = { "long-calls", "cpu=cortex-a8", "thumb" }
>
> define void @func() noinline ssp attrgroup(#1) {
>   ret void
> }
>
> Each target would know which options it can handle and how to parse them
> correctly. Code generation would use the attribute group referenced by the
> function to guide what code it emits.
>
> First Step
> ==========
>
> The first step of making a major change to attributes is to change the interface
> for creating them into something that works with different designs. This will
> allow the implementation to be swapped out independently of all the clients
> changing. It would then expose a very simple predicate interface. Building
> attributes for LLVM objects will be done with simple 'add*' methods:
>
> An example syntax could be:
>
> // Building an Attribute
>
> Attributes A;
> A.addAlignAttr(4)
>  .addNoUnwindAttr()
>  .addStackProtectorAttr()
>  .addUnwindTableAttr()
>  .addReadNoneAttr();
>
> // 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