[llvm-dev] AVR target, add llvm/Support/AVRTargetParser

Wed Sep 29 13:25:47 PDT 2021

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

Am Mon, Sep 27, 2021 at 10:23:13AM +0100 schrieb David Spickett:
>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