Hi Renato,> On 13 November 2010 15:12, Duncan Sands<baldrick at free.fr> wrote: >> I agree that it's limited. As for MC, it will need to handle these strings >> anyway since this is an existing LLVM feature (coming from gcc originally) >> that needs to be supported. > > Do you mean that LLVM-GCC generates build attributes as asm strings in IR?no, I mean that gcc supports file level ASM, which is why llvm-gcc and LLVM support it too, and which presumably means that MC will have to support it one day.>> Because magic globals need magic treatment, i.e. special logic in the code >> generators etc. Why add all this new stuff if an existing feature will do? > > Build attributes are not asm specific, and implementing them in an asm > specific keyword seems kludge to me. Not to mention that you lock the > IR in a ARM-GNU-ASM specific mode, which is a dead-end. Also, passing > ".build_attribute" strings in IR if you're producing ELF doesn't make > sense, IMO.It is hard for me to comment because I don't know anything about these attributes. However, presumably they need to end up in the .s file. I'm pointing out that you can put anything you like into the assembler via module level asm. I'm not sure what you mean by "build attributes are not asm specific". I never suggested they were! The so-called asm is just a directive saying: place this string as-is in the final assembler. I'm also not sure what ELF has to do with anything.> In a global array, the indexes are represented directly, only leaving > the associated string if additional information is necessary (like CPU > name, which is already a string).Since I don't know anything about these attributes, talk of indexes and so forth goes straight over my head. All I'm saying is that if you want a series of strings to end up in the .s file, this can be done using an existing LLVM feature. Ciao, Duncan.
On 13 November 2010 21:15, Duncan Sands <baldrick at free.fr> wrote:> Since I don't know anything about these attributes, talk of indexes and > so forth goes straight over my head.Hi Duncan, I assumed you knew what build attributes were in the first place, my mistake. For a full explanation of what they are, see ARM ABI Addenda, section 2.1 (PDF). (Google's first hit for "arm abi addenda"). Simply put, build attributes express the user explicit intentions when compiling code, so the linker can take better decisions when linking the objects. These attributes apply normally to whole units, but could apply to sections or even symbols, to express the compatibility or preference towards specific components. With build attributes, it's easier to pass information between tool chains, as some choices might be obvious within the tool chain, but different across. For example, the LLVM tool chain assumes that every Cortex-A8 has NEON, while the ARM tool chain does not. So, if you compile a file with Clang for Cortex-A8 and link with LLVM linker (or LD), everything works fine, because that assumption is in every step of the tool chain. However, if you try to link with armlink, it won't work, as the NEON attribute (Tag_Advanced_SIMD_arch) will not be there, and when it finds vector instructions, it'll bail out. Another example I quote from the ABI: "The compiler might choose to use only the Thumb ISA in a specific build of a source file. Nonetheless, the relocatable file should be tagged as having been permitted to use the ARM ISA so that a linker can later link it with ARM-state library code and generate ARM-state intra-call veneers if that gives benefit to the executable file. On the other hand, if the user intends code to be executed by both ARM7TDMI and Cortex-M3, the compiler must be constrained to generate only Thumb v1 instructions and the relocatable file should be tagged as not permitted to use the ARM ISA." So, as you can see, this gives the user and library writers freedom to optimize and specialize their code to perfection. In a highly segmented market such as ARM's, where every manufacturer has its own ways to connect the components or build SoCs, this is the only way to completely customize the tool chain to a completely customized architecture. Also, it's not something restricted to assembly only, but it's also stored in ELF files (global, sections, symbols). This are also well documented, long-lasting definitions that all ARM ABI compatible compilers should honour when producing and consuming object files. Specific manufacturer can also come up with a new set of attributes that are specific to their own architecture, and as long as they don't collide with the public definitions, other manufacturers are free to ignore. cheers, --renato
Hi Renato, everyone On Sat, Nov 13, 2010 at 2:17 PM, Renato Golin <renato.golin at arm.com> wrote:> On 13 November 2010 21:15, Duncan Sands <baldrick at free.fr> wrote: >> Since I don't know anything about these attributes, talk of indexes and >> so forth goes straight over my head. > > Hi Duncan, > > I assumed you knew what build attributes were in the first place, my mistake. > > For a full explanation of what they are, see ARM ABI Addenda, section > 2.1 (PDF). (Google's first hit for "arm abi addenda"). > > Simply put, build attributes express the user explicit intentions when > compiling code, so the linker can take better decisions when linking > the objects. These attributes apply normally to whole units, but could > apply to sections or even symbols, to express the compatibility or > preference towards specific components. With build attributes, it's > easier to pass information between tool chains, as some choices might > be obvious within the tool chain, but different across. > > For example, the LLVM tool chain assumes that every Cortex-A8 has > NEON, while the ARM tool chain does not. So, if you compile a file > with Clang for Cortex-A8 and link with LLVM linker (or LD), everything > works fine, because that assumption is in every step of the tool > chain. However, if you try to link with armlink, it won't work, as the > NEON attribute (Tag_Advanced_SIMD_arch) will not be there, and when it > finds vector instructions, it'll bail out. > > Another example I quote from the ABI: > > "The compiler might choose to use only the Thumb ISA in a specific > build of a source file. > Nonetheless, the relocatable file should be tagged as having been > permitted to use the ARM ISA so that a linker can later link it with > ARM-state library code and generate ARM-state intra-call veneers if > that gives benefit to the executable file. > On the other hand, if the user intends code to be executed by both > ARM7TDMI and Cortex-M3, the compiler must be constrained to generate > only Thumb v1 instructions and the relocatable file should be tagged > as not permitted to use the ARM ISA." > > So, as you can see, this gives the user and library writers freedom to > optimize and specialize their code to perfection. In a highly > segmented market such as ARM's, where every manufacturer has its own > ways to connect the components or build SoCs, this is the only way to > completely customize the tool chain to a completely customized > architecture. > > Also, it's not something restricted to assembly only, but it's also > stored in ELF files (global, sections, symbols). This are also well > documented, long-lasting definitions that all ARM ABI compatible > compilers should honour when producing and consuming object files. > Specific manufacturer can also come up with a new set of attributes > that are specific to their own architecture, and as long as they don't > collide with the public definitions, other manufacturers are free to > ignore.I think there are several common use cases for these attributes - 1. to mark what ISA a function is compiled for: (i.e. is it a thumb16/thumb32/ARM?) 2. to constrain the generated code to use specific co-processors. At least for case 2, the ARMTargetMachine/ARMSubtarget contains a distinct set of flags which should be output in the file scope section of the attributes For case 1, I don't know how common it is for the same executable to cross thumb boundaries - (given that16bit thumb has limits on register usage etc..) but I suppose its possible. For now, I agree with Renato that using the Module-Level Inline Assembly is probably not the right way to go - for example, some of the messyness of .cpu asm statement mapping to many FileScope attributes is the primary cause of the (likely) not-clean looking code that needs to go into the current .ARM.attributes emitter for ELF. What I would like to find out is the current set of supported ASM attributes by the current AEABI compiler. Once *that* info is available, we can go about sensibly factoring the required behavior in LLVM - Just my 2c. -jason> > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >