llvm dev - Oct 2014 - [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>

> 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

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