> Hi Duncan, > > This could work, but it's very limited. Besides, there's already an MC > build attribute infrastructure, one would have to interpret those > strings in the back-end to an MC construct then back again to ASM and > ELF. > > I don't see why having a magic global would be worse than using module asm...So, you mentioned that there should be no attributes that were not requested by the users, right? If that is so, can't you produce the asm in clang or you FE and have llvm never introduce new ones? LLVM itself doesn't use the attributes, so it doesn't need to interpret them.> --renatoCheers, Rafael
On Nov 17, 2010, at 2:55 PM, Rafael Espíndola wrote:>> Hi Duncan, >> >> This could work, but it's very limited. Besides, there's already an MC >> build attribute infrastructure, one would have to interpret those >> strings in the back-end to an MC construct then back again to ASM and >> ELF. >> >> I don't see why having a magic global would be worse than using module asm... > > So, you mentioned that there should be no attributes that were not > requested by the users, right? If that is so, can't you produce the > asm in clang or you FE and have llvm never introduce new ones? LLVM > itself doesn't use the attributes, so it doesn't need to interpret > them.Right, we do similar things for Objective-C metadata that there is no reason to represent in IR, the objc frontend (like clang) just produces module-level inline assembly blobs. -Chris
2010/11/17 Rafael Espíndola <rafael.espindola at gmail.com>:>> Hi Duncan, >> >> This could work, but it's very limited. Besides, there's already an MC >> build attribute infrastructure, one would have to interpret those >> strings in the back-end to an MC construct then back again to ASM and >> ELF. >> >> I don't see why having a magic global would be worse than using module asm... > > So, you mentioned that there should be no attributes that were not > requested by the users, right? If that is so, can't you produce the > asm in clang or you FE and have llvm never introduce new ones? LLVM > itself doesn't use the attributes, so it doesn't need to interpret > them.Another use for build attributes would be as a means to record the build flags selected for each translation unit so that LTO could know how to optimize/tune the result. This use seems more important to solve than the ARM attributes under discussion here. deep
> Another use for build attributes would be as a means to record the > build flags selected for each translation unit so that LTO could know > how to optimize/tune the result. This use seems more important to > solve than the ARM attributes under discussion here.If needed, these attributes should be per function, no? How do you handle "ld -r" ?> deep >Cheers, Rafael
Forgot to reply all to include the list. deep ---------- Forwarded message ---------- From: Sandeep Patel <deeppatel1987 at gmail.com> Date: 2010/11/17 Subject: Re: [LLVMdev] Build Attributes Proposal To: Rafael Espíndola <rafael.espindola at gmail.com> 2010/11/17 Rafael Espíndola <rafael.espindola at gmail.com>:>> Another use for build attributes would be as a means to record the >> build flags selected for each translation unit so that LTO could know >> how to optimize/tune the result. This use seems more important to >> solve than the ARM attributes under discussion here. > > If needed, these attributes should be per function, no? How do you > handle "ld -r" ?I suppose per-function is best. I'd argue that the ARM attributes are all per-function as well. My favorite example is __attribute__((pcs("aapcs-vfp"))) as a function attribute to select the calling convention. Maybe these attributes could referenced like metadata so they can be merged if identical? deep
On 17 November 2010 23:13, Sandeep Patel <deeppatel1987 at gmail.com> wrote:> I suppose per-function is best. I'd argue that the ARM attributes are > all per-function as well. My favorite example is > __attribute__((pcs("aapcs-vfp"))) as a function attribute to select > the calling convention. > > Maybe these attributes could referenced like metadata so they can be > merged if identical?LLVM IR already represents that as aapcs_vfpcc function attribute. cheers, --renato
2010/11/17 Rafael Espíndola <rafael.espindola at gmail.com>:> So, you mentioned that there should be no attributes that were not > requested by the users, right? If that is so, can't you produce the > asm in clang or you FE and have llvm never introduce new ones? LLVM > itself doesn't use the attributes, so it doesn't need to interpret > them.This comment is a bit misleading... First, The user chooses the cpu, fpu, calling convention, floating-point optimizations, instruction sets, etc. Most of it is encoded in the target triple (ex: thumbv6m), others in command-line options (-mcpu, -mfpu, etc). Based on that fact, yes, the build attributes are always requested by the user, but that's not the whole story. The user can request incompatible attributes (like thumbv4), so the compiler as to warn or stop. Some attributes in one object can be incompatible with another object, and it's up to the linker to recognized that, merge if possible or bail out otherwise. There is room for guessing, but the idea of the build attributes are precisely to reduce that guessing game as much as possible to force errors in compile time rather than run time. Second, as you know, build attributes are not exclusively assembly tags, they have to be printed to ELF as well, and the ARM ELF back-end will have to get that information somewhere. The best part of this information will come from SubTarget, as we discussed before, but some restrictions must come from somewhere else. So the LLVM back-end must interpret them when they come, and parsing asm is not the way I'd do it. However, depending on how you compile using LLVM, you might not need it in the IR. The reason is that the command-line options can be passed straight through ASM/ELF if you compile using some driver (clang, llvm-gcc). But that won't work if you compile to BC, than compile to ASM/ELF later. My personal opinion is that, independent on how you compile your file, the result should be the same. So, having build attributes in the IR is the only choice. One could argue that it's not necessary, the docs could cover that easily and we wouldn't have to add an extra complexity to the IR. Based on how Clang parameters for target triple work today (-ccc against -cc1 ...), I guess that decision was taken before, so that wouldn't be a first. But that's obviously not my call. I could go over the build attributes list to name a few important ones, but there're two that comes to my mind: ARM/Thumb interoperability and FP optimization level (IEEE, fast), both important for choosing the right libraries/calls at link time. I don't believe there is any other way of representing them in IR today... But I could be wrong, obviously... best, --renato
Hi Sandeep,> Another use for build attributes would be as a means to record the > build flags selected for each translation unit so that LTO could know > how to optimize/tune the result. This use seems more important to > solve than the ARM attributes under discussion here.why not have your build system just pass the appropriate flags directly to the linker? Also, suppose some files were compiled at -O1, others at -O3. If you do LTO then these files will all be linked together and optimized, but at what -O level? I think it would be wrong to have the linker make policy decisions like "optimize at the highest -O level seen" or "optimize at the lowest -O level seen". Better to have the user explicitly say what they want. But in that case is there any need to record the -O level in some special way in the module in the first place? Ciao, Duncan.