Mara Sophie Grosch via llvm-dev
2021-Sep-25 15:24 UTC
[llvm-dev] 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>
David Spickett via llvm-dev
2021-Sep-27 09:23 UTC
[llvm-dev] AVR target, add llvm/Support/AVRTargetParser
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