Bob Wilson
2014-Oct-24 16:48 UTC
[LLVMdev] Target specific info available to Clang (and others)
> On Oct 24, 2014, at 5:43 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > On 24 October 2014 08:33, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: >> On 24 October 2014 13:13, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>> lib/Target/ARM: only built if the ARM target is enabled. >>> lib/TargetInfo/ARM: always build. Include only info that clang wants >>> to use: parse fpu name, construct the datalayout. >> >> Yes! That's the final plan! >> >> So, TableGen would generate two sets of files, one public and another >> private. The former only containing high-level target descriptions, >> cpu names, feature combinations, etc and the latter containing >> everything else, from instructions to pipeline descriptions. >> >> The public stuff should be available somewhere other projects can >> access without having access to the other local files by accident. >> Projects should not include them directly, but they'll include files >> that include them, so the directory should be in the projects' paths, >> too. We also may need to get these new classes into a library on its >> own, no? > > Yes, a fpu-name to fpu-enum function would live is such a library. In > the above example TargetInfo would not be just a directory > organization, there would be a lib/libLLVMTargetInfo.a in the build > directory.We also need a way to know which intrinsics are available for the current target. Currently clang accepts all of them and you get a “cannot select” error from the backend if the intrinsic is not available. We now have the mechanism to provide a better diagnostic from the backend, but clang will do a better job of getting the source location right…. except that clang currently has no way to know details of the targets. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141024/88b9b25d/attachment.html>
Rafael Avila de Espindola
2014-Oct-24 16:55 UTC
[LLVMdev] Target specific info available to Clang (and others)
Sent from my iPhone> On Oct 24, 2014, at 12:48, Bob Wilson <bob.wilson at apple.com> wrote: > > >> On Oct 24, 2014, at 5:43 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> >>> On 24 October 2014 08:33, Renato Golin <renato.golin at linaro.org> wrote: >>>> On 24 October 2014 13:13, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>>> lib/Target/ARM: only built if the ARM target is enabled. >>>> lib/TargetInfo/ARM: always build. Include only info that clang wants >>>> to use: parse fpu name, construct the datalayout. >>> >>> Yes! That's the final plan! >>> >>> So, TableGen would generate two sets of files, one public and another >>> private. The former only containing high-level target descriptions, >>> cpu names, feature combinations, etc and the latter containing >>> everything else, from instructions to pipeline descriptions. >>> >>> The public stuff should be available somewhere other projects can >>> access without having access to the other local files by accident. >>> Projects should not include them directly, but they'll include files >>> that include them, so the directory should be in the projects' paths, >>> too. We also may need to get these new classes into a library on its >>> own, no? >> >> Yes, a fpu-name to fpu-enum function would live is such a library. In >> the above example TargetInfo would not be just a directory >> organization, there would be a lib/libLLVMTargetInfo.a in the build >> directory. > > We also need a way to know which intrinsics are available for the current target. Currently clang accepts all of them and you get a “cannot select” error from the backend if the intrinsic is not available. We now have the mechanism to provide a better diagnostic from the backend, but clang will do a better job of getting the source location right…. except that clang currently has no way to know details of the targets.Yes, that would be a reasonable thing to put in the library. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141024/9c830156/attachment.html>
Renato Golin
2014-Oct-24 17:17 UTC
[LLVMdev] Target specific info available to Clang (and others)
On 24 October 2014 17:48, Bob Wilson <bob.wilson at apple.com> wrote:> We also need a way to know which intrinsics are available for the current > target. Currently clang accepts all of them and you get a “cannot select” > error from the backend if the intrinsic is not available. We now have the > mechanism to provide a better diagnostic from the backend, but clang will do > a better job of getting the source location right…. except that clang > currently has no way to know details of the targets.You know, thinking about named registers, Clang accepts any valid register name for any target, so if you specify "eax" on ARM, clang will happily let it go, to fail on the back-end, so maybe even register names would be a valid thing to have available... I'm wondering what shouldn't we put in this public library... How big would this library end up? The size problem would only be a problem on small devices, when running native (like Android Renderscript or ARM JIT), since you don't *really* need all that bloat from all other targets. If that's a real problem, wouldn't the value of Clang being able to produce IR on all archs be overshadowed by it? I mean, we have three issues: 1. It's nice to have Clang generate IR for all archs on any arch 2. We need target info to do that, currently Clang duplicates everything 3. We don't want to bloat native binaries in restricted environments I'm beginning to think that the "nice" feature 1 is not worth the two big problems 2 and 3. If we tie Clang builds with back-end builds and force it not to have support for other arches (because the info isn't available if you don't build its back-end), than all that info can still be public and not completely bloat the final libraries. Is there any stronger reason why Clang must be able to generate IR for any arch on any arch? cheers, --renato
Rafael Espíndola
2014-Oct-24 18:17 UTC
[LLVMdev] Target specific info available to Clang (and others)
> I mean, we have three issues: > > 1. It's nice to have Clang generate IR for all archs on any arch > 2. We need target info to do that, currently Clang duplicates everything > 3. We don't want to bloat native binaries in restricted environments > > I'm beginning to think that the "nice" feature 1 is not worth the two > big problems 2 and 3. If we tie Clang builds with back-end builds and > force it not to have support for other arches (because the info isn't > available if you don't build its back-end), than all that info can > still be public and not completely bloat the final libraries. > > Is there any stronger reason why Clang must be able to generate IR for > any arch on any arch?Last time the idea of just using lib/Target was raised Alp mentioning having a use case for the current ability. Cheers, Rafael
David Chisnall
2014-Oct-25 09:02 UTC
[LLVMdev] [cfe-dev] Target specific info available to Clang (and others)
On 24 Oct 2014, at 18:17, Renato Golin <renato.golin at linaro.org> wrote:> I'm beginning to think that the "nice" feature 1 is not worth the two > big problems 2 and 3. If we tie Clang builds with back-end builds and > force it not to have support for other arches (because the info isn't > available if you don't build its back-end), than all that info can > still be public and not completely bloat the final libraries. > > Is there any stronger reason why Clang must be able to generate IR for > any arch on any arch?To clarify: Are you asking if there's a use case for clang being able to generate IR for architectures that it can't generate native code for? The only cases I can think of for this are special targets (SPIR, PNaCl), where there isn't a corresponding back end. If we can reduce the size of a build of clang that isn't a cross compiler, without reducing the utility of a build of clang that is a cross compiler, then this sounds like a good plan. We generally have two uses for clang: - On big machines, we want a few symlinks to clang for different targets - On small machines, we want as small a clang as possible, with only the features that are absolutely essential as a C compiler While we're discussing target-specific things though, there is one corner case that's come up a few times and is worth considering: A few people want to target a lowest-common-denominator architecture for most of the code and have some functions use intrinsics of inline assembly relying on features for something more specific (e.g. x86-64 base, SSE 4.2 in some functions) and then decide whether to use those specific functions at run time. We actually have a more general case of this, where we'd like to be able to embed some inline MIPS assembly in x86 and ARM binaries that are going to be used for controlling a MIPS-compatible coprocessor (or talking to it over JTAG). David
Possibly Parallel Threads
- [LLVMdev] Target specific info available to Clang (and others)
- [LLVMdev] Target specific info available to Clang (and others)
- [LLVMdev] Target specific info available to Clang (and others)
- [LLVMdev] The target independence of IR
- [LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter