Hi,
I'm currently working on adding some more builtin definitions to Clangs
AVR target (__AVR_DEVICE_NAME__, __AVR_ARCH__, __AVR_MEGA__,
__AVR_XMEGA__) to improve compatibility with avr-libc.
Currently the AVR specific code in clang has a big table, mapping each
MCU to it's definition name (atxmega128a4u -> __AVR_ATxmega128A4U__) and
for every MCU I'd need more info.
Instead of adding more info to this table, I made a new class in
llvm::Support, called AVRTargetParser. I've added a AVRTargetParser.def
to llvm/include/llvm/Support, containing all the device infos to be used
with macros (like ARMTargetParser.def).
While thinking how to reduce duplication, I'm now not sure if a def file
is the best way to do it. A lot of this info also already is in
llvm/lib/Targets/AVR/AVRDevices.td. I want to reduce the info there for
more specific stuff and use the AVRTargetParser for things it already
knows - but maybe instead of a def file a td file would be better?
Thanks for any comments 
Mara
Hi Mara, I've looked at this a few times for the Arm/AArch64 target
parsers. I had two goals, to make them smarter (extension y requires
x, extension z was first added in armv8.x etc.) and to share
information with the target backends.
The key problem I found with using tblgen is that a tablegen file
requires llvm-tblgen to build it. llvm-tblgen requires the Support
lib. The target parsers live in the Support library. And the loop
continues. See "Use of Table-gen" in
[llvm-dev] [RFC] New Clang target selection options for ARM/AArch64.
To do this, we would need to move TargetParser to break the cyclic dependency of LLVMSupport -> llvm-tblgen -> LLVMSupport. There are 2 options for this:
1. create a new LLVMTargetParser library that contains all parsers for architectures that use it.
2. put the TargetParser for each backend in the library group for that backend. This requires one of:
* Relaxing the requirement that target parsers must be built even if the backend is not.
* Modifying the CMake scripts to build the target parsers even if the backend is not being built.
Thinking about it now, you actually need both of those things for a
working solution.
Idea 1 was tricky because the target parsers are used by other
target-ish things like host and triple. I had a couple of ideas for
that:
* Move all the dependent things into the new library as well. Though
you risk creating another kitchen sink library (or a longer dependency
loop).
* Add a target parser library that exposes some interface
class/pointer. Then you can build Support as long as you then provide
the target parser lib at link time.
Which leads you into another loop, unless you make the references to
the target parser some kind of weak pointer so you can build
llvm-tblgen without it. (just an idea, I don't know whether this is
actually possible)
* Split support into a "CoreSupport" and "Support". "CoreSupport" can
be used to build tblgen then included in Support like normal later on.
This I found on a previous list thread:
https://lists.llvm.org/pipermail/llvm-dev/2017-May/113387.html
The response seemed to be that becuase this is introducing a sort
of 2 stage build, there needed to be a compelling reason to do it.
Perhaps this is that reason?
Idea 2 I did not get too far into. My understanding is that clang must
be able to understand target names and extensions and such even when
the target's backend is not built. Perhaps
there is room there for some subset of a target backend that is always
built. Or, we add a new library in llvm that pulls in some subset of
the target backends tablegen files.
Just my instinct, it would be good to see what the "CoreSupport" idea
would look like. Does it over complicate the build or is it actually
something cmake can handle quite well.
If we could do that, then the target parsers stay in Support and we
can "just" pull a subset of tablgen files from each target backend to
build the parsers.
If we could put our use cases together that'd be great and I'm happy
to help out on the Arm/AArch64 side. I think RISCV has also followed
the Arm/x86 approach so there is another potential use case.
Thanks,
David Spickett.
Hi,
oh, wasn't aware of llvm-tblgen needing the Support library - still am
fairly new in the codebase ^^'
And while it sounds interesting to find a way to be able to use tblgen
here, it's a lot over what I'm able to do, so I'll stick with a def
file for now - but thank you very much for your detailed response
Best,
Mara