Implementing address register classes

Hello everyone

I am currently writing the backend for a proprietary DSP which has separate address registers and a calling convention that allows addresses to be held only in them. This is similar to the case in the Tricore architecture detailed here. But as mentioned in the thesis paper, this was not straightforward to implement back in 2009.

My first question is, is it still the case today with respect to distinguishing between an integer type and pointer type at the Selection DAG level. If yes, how should I go about implementing the same?

I am just starting out with LLVM and this is my first big project, so I would appreciate any help. TIA!

M68k also separates address registers from data registers. In the case of calling convention, we use the CCCustom TableGen directive to designate pointer arguments via address registers
(The default M68k CC passes arguments by stack but we have a non-standard fast CC that passes by registers)

1 Like

SelectionDAG still doesn’t and will probably never support pointer typed values. GlobalISel does distinguish between integers and pointers. If it’s just for calling convention lowering, it’s possible to handle in the DAG.

1 Like

Your reply was very helpful. I have been skimming the implementation of M68k but I found that the specific calling convention that I am interested in (for pointers) is under a FIXME. It would be really helpful if you could give a high level overview of what has to be done to achieve completion for the same in my backend. I am very new to LLVM and I think that’s why I am unable to see if the fix for that is straightforward or not.

I found that the specific calling convention that I am interested in (for pointers) is under a FIXME

Though I forgot the exact reason, I think the missing feature is something about allocating all the pointer arguments before the data ones.

if you could give a high level overview of what has to be done to achieve completion for the same in my backend

M68k has a subclass of CCState (M68kCCState) that stores the llvm::Type of function arguments given by M68kTargetLowering::LowerCall, thus the custom CC function knows which argument is a pointer.
M68k’s fast CC (the CC I’m discussing here) is, unfortunately, not our top priority so I’m not really confident about it. But I believe it’s a good starting point that you can give a try.

1 Like

See the IsPointer field in ISD::ArgFlagsTy