[LLVMdev] Handling segmented instruction space in backend for custom target

Anoushe Jamshidi ajamshidi at gmail.com
Mon Nov 26 12:34:50 PST 2012


ping

Does anyone have any advice for handling a segmented address space as
described in my prior message?  I might have confused terminology, so
please let me know if the previous post was unclear.

-Anoushe


On Fri, Nov 16, 2012 at 12:09 PM, Anoushe Jamshidi <ajamshidi at gmail.com>wrote:

> Hi all,
>
> I'm building a backend for a custom target, and I'm trying to figure out
> how to handle global and external target address with my architecture's
> call instructions.
>
> This arch. has 16-bit addresses into a segmented address space, and to do
> a direct call I need to set both an instruction counter (IC, 10 bits wide)
> and an instruction segment register (ISR, 6 bits wide). My CALL instruction
> can set the IC, and a LISR instruction can load the ISR.  The ISR doesn't
> need to be set if the callee lives within the same instruction segment,
> i.e. it's not a far call, no LISR instruction needed.  If it is a far call,
> the LISR instruction precedes the CALL.
>
> 1) I'm not sure exactly how to transform the global & external target
> addresses, nor how to take the transformation and match them to my LISR &
> CALL instructions in my XXXInstrInfo.td TableGen file.  I've been looking
> at how the Mips target has hi/lo relocations to handle 16-bits of an
> address at a time, but I don't see how the relocations are inserted(?) into
> the patterns for the JAL/JALR nodes.  Does anyone have any advice on the
> best way to do this, and/or how the Mips addresses are handled?
>
> 2) I'm also not sure how (or at what stage of codegen) to check if the
> callee lives in the same instruction segment.  How can I compare a call
> instruction's address with that of its target?  If I can do this, I could
> remove (or maybe not select) LISR instructions when they are unnecessary.
>
> Maybe this is all elementary and I just haven't been searching for the
> right things, but I'm new at this and would greatly appreciate any help.
>
> Thank you,
> -Anoushe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121126/b290e7e6/attachment.html>


More information about the llvm-dev mailing list