[LLVMdev] Few questions about stack frame and calling conventions implementation in a backend

[Artur Pietrek]

Hi Andrew,
thanks for answering

On Thu, Apr 15, 2010 at 3:35 PM, Andrew Lenharth <andrewl at lenharth.org>wrote:

> On Thu, Apr 15, 2010 at 3:40 AM, Artur Pietrek <pietreka at gmail.com> wrote:
> > Hi all
> > Ups, I'm really sorry for that previous message, I've sent it by mistake.
> >
> > So let me write it once more.
> >
> > I've been working for some time now on a backend for our CPU. However I
> > couldn't figure out how to implement some stuff.
> > I'd appreciate your help with these.
> >
> > First thing is return address saving. To do that, first I have to copy it
> to
> > a general purpose register. I have no idea how to find an unused gpr
> > register in emitPrologue/emitEpilogue. I've noticed that in other
> backends
> > RegScavenger is used for that purpose, but not from inside of those
> methods.
> > So my question is how could I get an unused register from inside of these
> > methods?
>
> Do you have an API specified register where the variable is passed?
> If so, it is a matter of copying it to a virtual register in the
> prologue which is then a live in to the first basic block.  If you
> must have it in a specific register, you can make your ret inst take
> it as a use and copy the virtual register back to the physical one for
> the ret.
>

There is no specific register needed here. It's just dedicated RA register
is a special register that could be read/set via a GPR using get/set
instructions only. So this is why I need a GPR register in
prologue/epilogue.
Aren't prologue/epilogue run after register allocation? If I copy to a
virtual register, wouldn't I have to rerun the RA pass?


>
> > And my second problem is with returning structures by value. ABI says
> that
> > aggregates up to 32bytes should be returned directly in register. Any
> advice
> > how this could be done?
>
> This has to be done in the front end, I think.
>

There is no way of doing that in the backend?


>
> Andrew
>

Thanks,
Artur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100416/8936abd2/attachment.html>