Renato Golin
2014-Oct-23 13:50 UTC
[LLVMdev] Target specific info available to Clang (and others)
So, In order to fix bug PR20787 (common parsing infrastructure for FPU options between LLVM and tools), I need to create a parser in LLVM that has all targets' information (types of fpus, cpus, archs, etc) but that can also be visible by external tools. Until now, all that information has been hidden from view by creating them with TableGen and leave them only visible to the target files. That makes a lot of sense, but I need some of that exposed. Including generated files from LLVM works ok, but Clang can't see them. If I enable Clang to see them (by adding the include dir on the path), there will be nothing to stop people from including more than they should. The kind of information I want to expose are the enums that identify features, mainly VFP/NEON/Crypto etc. This is in ARMGenSubtargetInfo.inc under GET_SUBTARGETINFO_ENUM. One way I could think of, but it's controversial, is to generate two files: ARMGenSubtargetInfo.inc and ARMGenSubtargetInfoPublic.inc, the former in the current directory, the latter in a shared include path for all tools. That way, not only LLVM, but also Clang, llc, lld etc would be able to use the same parsing mechanism and understand the generated data (enums, structures) in the exact same way. Attached are two pseudo-patches that illustrate the problem. The Clang patch shows how much more powerful could such infrastructure become. The patch doesn't compile on Clang because Clang cannot see ARMGenSubtargetInfo.inc. References: http://llvm.org/bugs/show_bug.cgi?id=20787 http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-August/038699.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140811/231052.html cheers, --renato -------------- next part -------------- A non-text attachment was scrubbed... Name: fpuparse-clang.patch Type: text/x-patch Size: 4297 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141023/d30ed8f7/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: fpuparse-llvm.patch Type: text/x-patch Size: 12467 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141023/d30ed8f7/attachment-0001.bin>
Rafael EspĂndola
2014-Oct-24 12:13 UTC
[LLVMdev] Target specific info available to Clang (and others)
> One way I could think of, but it's controversial, is to generate two > files: ARMGenSubtargetInfo.inc and ARMGenSubtargetInfoPublic.inc, the > former in the current directory, the latter in a shared include path > for all tools. That way, not only LLVM, but also Clang, llc, lld etc > would be able to use the same parsing mechanism and understand the > generated data (enums, structures) in the exact same way.I think this should move a bit further. One feature that we have now and people seem to find desirable is that clang can produce .ll files for target X even if target X is not compiled. In general the problem we have then is that there is a tiny bit of information about a given target that we want to build even when the target is not enabled. This means we should probably have something like 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. Cheers, Rafael
Renato Golin
2014-Oct-24 12:33 UTC
[LLVMdev] Target specific info available to Clang (and others)
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? cheers, --renato