[cfe-dev] Target Specific Parsing API
rafael.espindola at gmail.com
Mon Aug 18 14:58:42 PDT 2014
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.
It includes target options like -mfpu, but should also include things
like creating the DataLayout string which is currently duplicated in
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.
On 16 August 2014 08:43, Renato Golin <renato.golin at linaro.org> wrote:
> Following the discussion with Nico and others, I've created PR20683 to
> discuss about the implementation of a generic and externalised target
> specific parsing API for LLVM, Clang and others.
> I have a vague plan involving a generic class (say TargetParser) in
> lib/Target that is accessible as an API to any tool that needs target
> specific parsing. The idea is then to let targets implement their own
> versions of it on a generic part of the code (still lib/Target) so
> that we don't break tools if we don't build every back-end (or any
> back-end) with LLVM. Maybe this could be fixed on CMake, maybe not.
> This class should also allow for customization from the part of the
> tools, to either add functionality to existing functions (like
> pre-parsing, post-parsing, de-mangling etc) or adding completely new
> Also, since a common side effect of parsing architectural parameters
> is to set flags in specific classes, we should expect that every tool
> will *have* to override the "updateFlags" method inside the tool
> (including LLVM's integrated assembler) to use their own
> target-specific structures.
> I'm hoping that this makes sense. Please let me know if there's any
> major flaw, or existing infrastructure that we could be re-using. But
> from the looks of target parsing in both LLVM and Clang, there
> isn't... :/
More information about the cfe-dev