[LLVMdev] Target Specific Parsing API

Renato Golin renato.golin at linaro.org
Tue Aug 19 02:34:40 PDT 2014


On 18 August 2014 22:58, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:
> Note that it is not just option parsing. It is about the bits of
> information about a target that we expect to be available even when
> that target is not compiled.

Exactly, this is why the sub-arch information needs to be
tool-specific, but the parsing (even of the DataLayout) doesn't, since
this is identical to all tools.

Either returning agreed enum values, or letting the implementation
override some methods or even using template policies would do the
trick. We just need to find the simplest implementation for this case.


> A slightly different option would be to just require the llvm targets
> to implement a virtual interface, but that would mean that something
> as basic as
>
> clang -target armv7-pc-linux -### -c test.c
>
> would fail if the llvm arm backend was not compiled.

Oh, so there's why I think the bit setting needs to be tool-specific.
Clang has its own way of setting the arch bits, and this ArchParser
doesn't know anything about it, nor it should.

Let me give it a try, completely untested...

In LLVM: lib/Target/ArchParser.cpp:
 ArchParser {
    parseFPU() override;
    parseCPU() override;
    ...
    setFPUBits() override;
    setCPUBits() override;
  }
  ARMArchParser : public ArchParser {
     parseFPU() { ... }
     parseCPU() { ... }
    ...
  }
  X86ArchParser : ...


In Clang: lib/Driver/ArchParser.cpp:
  template <class BaseArchParser>
  ClangArchParser : public BaseArchParser {
    setFPUBits() { ... };
    setCPUBits() { ... };
    ...
  }
 ArchParser GetArchParser(StringRef TargetName) { if ("ARM") return
ClangArchParser<ARMArchParser>(); ... }

in llc, lli, lld, integrated assemblers, do like Clang.


ClangArchParser's setFPU will have nothing from the ARM back-end in
it, because its bits will be clang-specific. I know this still keeps
ARM knowledge in Clang, but it moves into a specific area that other
parts of Clang can access, and will help us leave the Clang-specific
sub-arch knowledge in Clang, and ARM specific option parsing in LLVM.

Currently, the behaviour is to allow for all options to work on -###,
including all back-ends that aren't compiled, and that's how Clang
tests behave. To change that would need a major change in the tests.
If we really want to soft-fail -### and relatives when a back end is
not compiled, we'll have to find a solution for it in addition to
change all the tests. But that's step 2.

cheers,
--renato




More information about the llvm-dev mailing list