Steps to implement codegen for a new target (newbie question)

Hi,

I want to roughly figure out the steps/modules to implement a codegen for a new architecture (like a high level design doc). I also need to do a rough estimation of how much time would be needed to implement each module, this may be not easy. Any pointers/references would be highly appreciated.

Thanks!

Maybe the following links help you:
https://llvm.org/docs/GlobalISel/Porting.html

https://llvm.org/docs/WritingAnLLVMBackend.html

And the first commit of the new PowerPC GlobalISel port:
https://reviews.llvm.org/D83100

1 Like

Thanks a lot tschuett!

GlobelISel is the new instruction selector. You still need to define your registers, instructions, …
The link in the middle gives you some ideas.

1 Like

Great tschuett, after implementing the skeleton for GlobalISel Skeleton for one instruction (ret void) as seen in ⚙ D83100 [PPC][GlobalISel] Add initial GlobalIsel infrastructure, what are the next steps. I see PPC.td and PPCRegisterBanks.td files in your skeleton. Wondering when to implement other td files and in what order. Ideally, I would like to implement one instruction at a time but even to do that, it looks like we need all the td files in place. Thanks a lot. Your skeleton link is very useful!

The Link above “Writing an LLVM Backend” should guide you in which tds you have to write.
e.g. AARCH64

Another PowerPC Diff:
https://reviews.llvm.org/D127530
https://reviews.llvm.org/D137785

2 Likes

Although I have declared my DummyRegisterInfo.td in the way other existing Targets have declared, I get this compilation error while including the DummyGenRegisterInfo.inc file in the DummyRegisterInfo.cpp. I am not sure if this is anyway related to GISel code. I am using llvm 14 codebase.

Thanks for your help.

[ 79%] Building CXX object lib/Target/Dummy/CMakeFiles/LLVMDummyCodeGen.dir/DummyRegisterInfo.cpp.o

In file included from **.../llvm/lib/Target/Dummy/DummyRegisterInfo.cpp:26:0**:

**../build/lib/Target/Dummy/DummyGenRegisterInfo.inc:414:30:** **error:** ‘**MRegsRegClassID**’ was not declared in this scope

&DummyMCRegisterClasses[**MRegsRegClassID**],

The DummyGenRegisterInfo.inc looks okay to me.

412 namespace Dummy {   // Register class instances
413   extern const TargetRegisterClass MRegsRegClass = {
414     &DummyMCRegisterClasses[MRegsRegClassID],
415     MRegsSubClassMask,
416     SuperRegIdxSeqs + 0,
417     LaneBitmask(0x0000000000000001),
418     0,
419     0x00, /* TSFlags */
420     false, /* HasDisjunctSubRegs */
421     false, /* CoveredBySubRegs */
422     NullRegClasses,
423     nullptr
424   };
425 
426 } // end namespace Dummy

This declaration too seems to be right.

43 namespace Dummy {
 44 enum {
 45   MRegsRegClassID = 0,
 46 
 47 };
 48 } // end namespace Dummy

Any idea what might be going wrong here? It looks like DummyRegisterInfo.cpp is a must in order for GISel code to even compile. Not sure why there is this dependency.

Thanks !

1 Like

Wild guess:

The enum is usually declared in DummyMCTargetDesc.h, which is often included in top level file Dummy.h. The error looks like you need to create/include those files in DummyRegisterInfo.cpp.

That is not really related to GISel, it is the common code required for all instruction selection algorithms.

Regards,
Kai

1 Like

Hi Kai,
I was able to go past the error after including the files that you recommended. Thanks a lot.
I am trying to implement a target bottom up from scratch and unfortunately get compilation errors that are hard to even figure out why they occurred. Wondering if you have any advice/links recommendations to this. I recently found CPU0 book (Table of Contents — Tutorial: Creating an LLVM Backend for the Cpu0 Architecture) but it doesn’t have GISel in it.

Some recommend copying an existing Target and renaming it to the new target and work top down. This too seems pretty tedious as many files are either irrelevant or a given target doesn’t have everything one is looking for. I tried BPF as it is smaller but it doesn’t have GISel code, and also mine is accumulator based architecture where BPF isn’t. It looks like we have to refer to many targets to implement our Target.

Regards!