similar to: [LLVMdev] [RFC] Overhauling Attributes

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)

Hi Bill, > 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.

> attrgroup #1 = { "long-calls", "cpu=cortex-a8", "thumb" } > > define void @func() noinline ssp attrgroup(#1) { > ret void > } > I like the general idea. Just one clarification: In the above example, are the attributes taken from a list specified in the language ref (like current attributes) or can they be arbitrary "strings" (like

Hi Rafael, Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. -bw On Oct 4, 2012, at 7:47 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> attrgroup #1 = { "long-calls", "cpu=cortex-a8", "thumb" }

Hi Bill, On 30/12/12 03:21, Bill Wendling wrote: > Hi Rafael, > > Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. this sounds so much like metadata... What was the reason for not enhancing metadata to cover this use case? I'm sure you explained

On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > IR Changes > ---------- > > The attributes will be specified within the IR. This allows us to generate code > that the user wants. This also has the advantage that it will no longer be > necessary to specify all of the command line options when compiling the bit code > (via 'llc' or 'clang'). E.g.,

Hi! This is a proposal to expand the Attributes class to support many different options that will be accessible by all parts of the compiler. Please read and give any feedback you may have. Thanks! -bw Passing Options to Different Parts of the Compiler Problem ======= There is a growing need to pass information from the front-end to different parts of the compiler, especially

On Nov 20, 2012, at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to specify

On Tue, Nov 20, 2012 at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to

On Nov 26, 2012, at 3:20 PM, Bill Wendling wrote: >> 4. Do we really want the attribute references limited to a number? Code will be more readable >> if you can use actual names that indicate the intent. For example: >> >> attrgroup #compile_options = { … } >> void @foo attrgroup(#compile_options) >> > The problem with this is it

On 13 February 2013 19:37, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Is anyone currently working on overhauling the command-line processing code? > I'm currently doing some work on the CommandLine library but I don't think my work is going to help you. I'm current working on... - Allowing declared command line options to be put into categories to allow a

On 29 December 2012 21:21, Bill Wendling <wendling at apple.com> wrote: > Hi Rafael, > > Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. But then, what are the semantics that the middle end should use? Can a non thumb function be inlined in a

I would like to add something to atttributes.h, attributes.cpp in the interim until your full scheme is available. A new attribute called "target" would be added to AttrKind. And target can take a list of strings. target("foo", "goo") For example. I would add a component targetAttrs to AttrBuilder Will this meet with resistance if I try and put this back? Reed

Looks like new attribute work is moving along quickly Maybe I should just wait. ??? On 01/11/2013 03:09 PM, Reed Kotler wrote: > I would like to add something to atttributes.h, attributes.cpp in the > interim until your full scheme is available. > > A new attribute called "target" would be added to AttrKind. > > And target can take a list of strings. > >

On Feb 13, 2013, at 2:32 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > > This is a very interesting one that is orthogonal to Bill's work. The preferred approach for this sort of thing is to change the LoopUnroll pass to take the unroll threshold as a constructor argument or a struct that wraps up all of the configuration settings. When the pass is *default*

Hi! The rewrite of the attributes class is well underway. The next step is to add support for the expanded rôle of attributes in the language and IR. This is the final proposal for the language changes. There isn't a lot of new information except for the syntax changes for the new feature. Executive Summary: The new syntax is: #0 = attributes { noinline align=4

Reply to list as I had originally intended... ---------- Forwarded message ---------- From: Justin Holewinski <justin.holewinski at gmail.com> Date: Wed, Feb 13, 2013 at 4:23 PM Subject: Re: [LLVMdev] Overhauling the command-line processing/codegen options code To: Chris Lattner <clattner at apple.com> On Wed, Feb 13, 2013 at 3:53 PM, Chris Lattner <clattner at apple.com>

On Dec 31, 2012, at 4:37 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Bill, > > On 30/12/12 03:21, Bill Wendling wrote: >> Hi Rafael, >> >> Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. > > this sounds so much

Is anyone currently working on overhauling the command-line processing code? We're currently having some design issues with this component, and I'd like to start a larger conversation on it. For context, I am talking from an "LLVM as a library" perspective instead of an "LLVM as a set of tools" perspective. In a nut-shell, the problems we are facing are as follows:

> To use an attribute group, an object references the attribute group's ID: > > attribute_group_ref := attrgroup(<attrgroup_id>) Is this unused now? I don't see it anywhere else in the proposal. -- Sean Silva