On Nov 12, 2010, at 8:20 AM, Duncan Sands wrote:> Hi Renato, > >> So, after long rounds to define how the build attributes are going to >> be represented in IR, and after Jason has implemented build attributes >> in MC, I have a proposal on how to represent this in IR. >> >> First, we need to distinguish between target dependent and independent >> attributes. Generic things like optimization level, specific >> optimizations, use of vector instructions, use of exceptions, >> floating-point compatibility can all go in to the generic list of >> attributes. > > I don't see why you would want to put any of these things in the module > at all:In fact they are more suitable as function attributes. For example, we already have function attributes for -Os. - Devang> > * optimization level: if you want the linker to optimize at -O3, I think > you should just pass -O3 to the linker. I don't see why the fact that > the original files were optimized at -O3, -O0, -O0 and -O3 (for example) > is relevant to link time optimization. > > * specific optimizations: likewise. > > * use of vector instructions: if you want the linker to codegen for SSE3, > then pass -msse3 to the linker. > > * use of exceptions: if a file is compiled with -fno-exceptions then > all functions have the nounwind attribute and contain no invokes. > This is all that is needed to automatically have the code generators > not generate unwind info for them, so no special module level attribute > is needed, everything is there already. > > * floating point compatibility: not sure what you mean by this. > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Devang, On 12 November 2010 18:13, Devang Patel <dpatel at apple.com> wrote:>> I don't see why you would want to put any of these things in the module >> at all: > > In fact they are more suitable as function attributes. For example, we already have function attributes for -Os.Well, if it's a compilation parameter (rather than a function attribute), applying to all functions in a module doesn't make all that sense, but I guess one could do that. I was trying to avoid pollution of the LangRef and moving it to a target specific namespace. You don't have to implement it in your front-end if you don't want. In that case, the back-end will assume all the defaults are to be selected and act as it would today. But if the compiler want's to pass those options any time, they should be allowed to and that should be carried throughout the compilation life time (front to back end) and honoured by every pass.> I think missing a point here. Are you proposing that linker selects libraries based on attributes encoded in IR ?That was just a top-of-my-head example but, yes. The behaviour of the compiler and linker could change in face of the build attributes. But, as I said, you're free to ignore it completely if you want. You could have an ARM compatibility mode that only regards build attributes when in this mode. That would make it much easier to compile using ARM+LLVM tools. We originally thought we could use metadata, but it would have to be linked to a global variable, and there's no point of having a global variable just for that. cheers, --renato
On Nov 12, 2010, at 10:13 AM, Devang Patel wrote:> > On Nov 12, 2010, at 8:20 AM, Duncan Sands wrote: > >> Hi Renato, >> >>> So, after long rounds to define how the build attributes are going to >>> be represented in IR, and after Jason has implemented build attributes >>> in MC, I have a proposal on how to represent this in IR. >>> >>> First, we need to distinguish between target dependent and independent >>> attributes. Generic things like optimization level, specific >>> optimizations, use of vector instructions, use of exceptions, >>> floating-point compatibility can all go in to the generic list of >>> attributes. >> >> I don't see why you would want to put any of these things in the module >> at all: > > In fact they are more suitable as function attributes. For example, we already have function attributes for -Os.I think some of this discussion is missing the context. ARM has defined per-object file build attributes to record things like the optimization level, whether the code is ARM vs. Thumb, etc. This is not something new nor is it specific to LLVM. As far as I know, the linker is not obligated to do anything with this information, but compilers that follow ARM's specifications are expected to provide it. Putting the build attributes on individual functions is not a good match for the final result, which is a single set of attributes for the entire object file. If you put separate attributes on the functions, then code gen will have to scan all the functions to see if they have the same attribute values.
On Nov 12, 2010, at 11:22 AM, Renato Golin wrote:> Hi Devang, > > On 12 November 2010 18:13, Devang Patel <dpatel at apple.com> wrote: >>> I don't see why you would want to put any of these things in the module >>> at all: >> >> In fact they are more suitable as function attributes. For example, we already have function attributes for -Os. > > Well, if it's a compilation parameter (rather than a function > attribute), applying to all functions in a module doesn't make all > that sense, but I guess one could do that.It would help you solve the case where to module with different attributes are merged together. However, Bob is correct, I was missing the context. Sorry about the confusion. - Devang
On 12 November 2010 19:53, Bob Wilson <bob.wilson at apple.com> wrote:> I think some of this discussion is missing the context. ARM has defined per-object file build attributes to record things like the optimization level, whether the code is ARM vs. Thumb, etc. This is not something new nor is it specific to LLVM. As far as I know, the linker is not obligated to do anything with this information, but compilers that follow ARM's specifications are expected to provide it.Sorry about that, I didn't want to sound redundant after my previous round of emails about build attributes... ;)> Putting the build attributes on individual functions is not a good match for the final result, which is a single set of attributes for the entire object file. If you put separate attributes on the functions, then code gen will have to scan all the functions to see if they have the same attribute values.Precisely. cheers, --renato
Hi Bob,>>>> So, after long rounds to define how the build attributes are going to >>>> be represented in IR, and after Jason has implemented build attributes >>>> in MC, I have a proposal on how to represent this in IR. >>>> >>>> First, we need to distinguish between target dependent and independent >>>> attributes. Generic things like optimization level, specific >>>> optimizations, use of vector instructions, use of exceptions, >>>> floating-point compatibility can all go in to the generic list of >>>> attributes. >>> >>> I don't see why you would want to put any of these things in the module >>> at all: >> >> In fact they are more suitable as function attributes. For example, we already have function attributes for -Os. > > I think some of this discussion is missing the context. ARM has defined per-object file build attributes to record things like the optimization level, whether the code is ARM vs. Thumb, etc. This is not something new nor is it specific to LLVM. As far as I know, the linker is not obligated to do anything with this information, but compilers that follow ARM's specifications are expected to provide it. > > Putting the build attributes on individual functions is not a good match for the final result, which is a single set of attributes for the entire object file. If you put separate attributes on the functions, then code gen will have to scan all the functions to see if they have the same attribute values.thanks for the explanation. Perhaps you can use global asm statements for this (see http://llvm.org/docs/LangRef.html#moduleasm )? These can be used to inject arbitrary strings into the assembler. Dragonegg uses this to provide an "ident" string like this: $ gcc-4.5 -fplugin=dragonegg.so -S -o - -flto empty.c ; ModuleID = 'empty.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" module asm "\09.ident\09\22GCC: (GNU) 4.5.2 20101028 (prerelease) LLVM: 118890\22" In the assembler output this gives: $ gcc-4.5 -fplugin=dragonegg.so -S -o - empty.c .file "empty.c" .ident "GCC: (GNU) 4.5.2 20101028 (prerelease) LLVM: 118890" .section .note.GNU-stack,"", at progbits Ciao, Duncan.