similar to: [LLVMdev] [RFC] Passing Options to Different Parts of the Compiler Using Attributes

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

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

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

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

> 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 Arnaldo, On 05/11/12 10:02, Arnaldo wrote: > Hi Duncan, thanks for the quick answer. > > Yes I'm sure the runOnModule is being called, and when I dump the functions > before exiting the method I can see the AlwaysInline attribute. > > I'll check InlineAlways.cpp and will reimplement as last resource but I still > wonder why this is not working. if you want more

Hi Duncan, thanks for the quick answer. Yes I'm sure the runOnModule is being called, and when I dump the functions before exiting the method I can see the AlwaysInline attribute. I'll check InlineAlways.cpp and will reimplement as last resource but I still wonder why this is not working. On Mon, Nov 5, 2012 at 5:03 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arnaldo,

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

This was replaced by having a #<num> referenced by the object. Kind of like how metadata is referenced. -bw On Feb 3, 2013, at 4:50 PM, Sean Silva <silvas at purdue.edu> wrote: >> 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

> 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

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

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

Well, I updated to cmake 2.8.12.2 but the result of changing that COMPILE_FLAGS to COMPILE_OPTIONS is that quotes are applied incorrectly: quotes are added surrounding the entire set of flags rather than around each individual item in the list. Obviously the build doesn't work (with the compiler looking for files named " -m64 ... ") but checking the relevant build command in

I have this test case in my frontend, which is triggering an assert in llvm master branch: fn fnWithAlignedStack() -> i32 { @setAlignStack(1024); return 1234; } It sets alignstack=1024 in the function attributes (see http://llvm.org/docs/LangRef.html#function-attributes). It's tripping an assert: llvm/lib/IR/Attributes.cpp:134: static llvm::Attribute

A couple of llvm sub-projects have been failing to build for me for a while (compiler-rt asan and util/unittests, at least). It turns out to be due to the fact that some paths on my system include spaces and other special characters, but the the build.ninja file was not generated with correctly quoted strings. Specifically I'm on OS X and the command is setting -isysroot to a location inside

Hi, I'm trying to fix an issue with clang's __force_align_arg_pointer__ attribute. The problem is described here: https://llvm.org/bugs/show_bug.cgi?id=26662 The problem is affecting Wine (https://www.winehq.org/) where we have a function that is an entry-point for the x86 Win32 abi. That function may then call functions in the host's (linux, OS/X, ...) abi. The issue is that the