llvm dev - Sep 2021 - AVR target, add llvm/Support/AVRTargetParser

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210925/9691f90c/attachment.sig>

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
https://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html.
> 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.

On Sat, 25 Sept 2021 at 16:24, Mara Sophie Grosch via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev