[LLVMdev] Target Specific Parsing API

[Renato Golin]

On 18 August 2014 17:53, Philip Reames <listmail at philipreames.com> wrote:
> Could you give a couple of examples where this would be useful?  I find
> myself without the context to really understand your proposal. Are we
> discussing target specific language extensions?  Assembly parsing?
> Something else entirely?

Hi Philip,

Sorry, the bug track (two, for now) should have more context, but
here's a summary:

Nico started trying to solve a problem where ".fpu neon" wouldn't
change the instruction set in an assembly file, and he found that he
needed a parser identical to the one in Clang to parse the exact same
semantics ("neon", "vfpv3", etc). The ARM assembly also has a .cpu
which is pretty much the same story, so he thought that we could share
the parser on both sides, maybe exposing some functionality from LLVM
to Clang.

The problem, as Reid mentioned, is that LLVM doesn't need to compile
with all back-ends, and implementation in a back-end that is not
compiled will generate link time errors on a statically compiled Clang
or run time errors on a dynamically compiled Clang. But this also
opens a can of worms, where we start to leak target specific knowledge
from the back door, without a properly defined API that has to be
respected over the years, once everyone else has forgotten that we've
done that.

I blocked such a patch from going in, because we'd be replacing code
duplication with implicit coupling of far away pieces of code, but now
that the original problem is solved (by duplicating code), we have to
fix the duplication problem. Since duplication was already there,
especially in the sub-arch parsing, we should be able to sweep a few
of other similar bugs away with a single fix.

Since parsing of strings is generic, and should be used by all tools
(that support -mfpu), that piece of code can live in lit/Target and
Clang can rest assured that it'll be there. But the second part, the
Clang-specific one, will only live in Clang, and use Clang's own
structures to hold and change the sub-architecture feature flags
wherever it's needed. Same for all other tools, and same for MC
assembler.

So, as an example in the assembler case, parseDirective sees ".fpu",
calls parseDirectiveFPU which uses ArchParser->parseFPU() returning an
enum/bitfield owned by ArchParser, which is then relayed to the
assembler so it can call setAvailableFeatures(FPU);

In Clang, the driver will observe -mfpu and call
ArchParser->parseFPU() which, again, will return the same
enum/bitfield to the driver, which will then update its own flags to
-cc1, etc.

We can use enum/bitfields as a communication method, re-using most of
what's in use right now to identify those things, but move into one
single place. That would be the quick and simple solution. If it turns
out we need some more complex fiddling, we might have to create some
call-backs (virtual preParse(), virtual postParse() that do nothing on
the base class) etc, so that Clang can override them and do what's
needed, but that's only if we can't do it straight with enums.

cheers,
--renato