Anoushe Jamshidi
2012-Nov-16 20:09 UTC
[LLVMdev] Handling segmented instruction space in backend for custom target
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/20121116/13c736e6/attachment.html>
Anoushe Jamshidi
2012-Nov-26 20:34 UTC
[LLVMdev] Handling segmented instruction space in backend for custom target
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>