similar to: [LLVMdev] [RFC] Attributes Rewrite (Final)

On Jan 29, 2013, at 2:42 PM, Bill Wendling <isanbard at gmail.com> wrote: > Executive Summary: > > The new syntax is: > > #0 = attributes { noinline align=4 "cpu"="cortex-a8" } > #1 = attributes { attr = (val1 val2 val3) } > #bork = attributes { sspreq noredzone } > > define void @foo() #0 #bork { ret void } The general syntax LGTM. It

On Feb 3, 2013, at 10:45 AM, Chris Lattner <clattner at apple.com> wrote: > On Jan 29, 2013, at 2:42 PM, Bill Wendling <isanbard at gmail.com> wrote: >> Executive Summary: >> >> The new syntax is: >> >> #0 = attributes { noinline align=4 "cpu"="cortex-a8" } >> #1 = attributes { attr = (val1 val2 val3) } >>

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

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 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 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 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

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. > >

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" }

On Feb 3, 2013, at 12:55 PM, Bill Wending <isanbard at gmail.com> wrote: >>> The 'align' and "cpu" attributes both have a value associated with them. The 'attr' attribute in '#1' has multiple values associated with it. (The BNF is below in the 'IR Changes' section.) Attribute groups with the same attributes in them, but in a different order,

Couple of quick questions: First, what are the valid types for <value>? Are they always strings which the target must interpret, or will numeric literals and booleans also be supported? Also, in the proposal, attributes are sometimes quoted and sometimes they are not. I know this is nit-picking, but what is the preferred syntax? Second, would it make sense to fold the calling convention

> 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

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

Hello, I plan to implement "Stack Smashing Protection - Strong" support in LLVM. Below is a description of this feature and an overview of the implementation plan. I have divided up the implementation into stages that can be delivered incrementally. I'm looking for any feedback (suggestions, requests, etc) before I actually begin the work. Thank you! Josh

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

> 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 all, I'm a beginner user of R. I am stuck at what I thought was a very obvious problem, but surprisingly, I havent found any solution on the forum or online till now. My problem is simple. I have a file which has entries like the following: #ID Value1 List_of_values ID1 0.342 0.01,1.2,0,0.323,0.67 ID2 0.010 0.987,0.056,1.3,1.5,0.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.