Sanjiv.Gupta at microchip.com
2008-Aug-06 10:54 UTC
[LLVMdev] Modeling 16-bit pointer registers for an 8-bit target
Pointer size on our target is 16-bits, and we have two 16-bit registers that can be used only to hold pointers (indirect addresses). All operations on the target are 8-bit operations, so it takes two 8-bit loads to load these pointer registers. We want LLVM to automatically expand all types to 8-bit values. The problem is that LLVM does not expand GlobalAddresses, which are 16-bit values. This in turn means that you have to specify a 16-bit register class, and once you specify a 16-bit register class, LLVM does not further expand 16-bit values. Any suggestions on how to model this into LLVM? TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080806/9822aa0c/attachment.html>
Evan Cheng
2008-Aug-06 20:36 UTC
[LLVMdev] Modeling 16-bit pointer registers for an 8-bit target
On Aug 6, 2008, at 3:54 AM, Sanjiv.Gupta at microchip.com wrote:> Pointer size on our target is 16-bits, and we have two 16-bit > registers that can be used only to hold pointers (indirect addresses). > > All operations on the target are 8-bit operations, so it takes two 8- > bit loads to load these pointer registers. > > We want LLVM to automatically expand all types to 8-bit values. > > The problem is that LLVM does not expand GlobalAddresses, which are > 16-bit values. > This in turn means that you have to specify a 16-bit register class, > and once you specify a 16-bit register class, LLVM does not further > expand 16-bit values.I don't think there is code in Legalizer to expand GlobalAddress. But you can custom lower it. X86 custom lower GlobalAddress nodes for a different reason. Evan> > Any suggestions on how to model this into LLVM? > > TIA, > Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080806/ff7dfd0e/attachment.html>
Dan Gohman
2008-Aug-06 20:53 UTC
[LLVMdev] Modeling 16-bit pointer registers for an 8-bit target
Legalize uses two primary predicates, isTypeLegal and isOperationLegal. I guess your target tells Legalize that i16 as a legal type. The next step is to tell legalize that loading a 16-bit GlobalAddress is not a legal operation. If you do that and it still doesn't work, it's a likely indication that Legalize is making an assumption that isn't valid for your rather unique architecture, and you should investigate correcting that assumption. Dan On Aug 6, 2008, at 3:54 AM, Sanjiv.Gupta at microchip.com wrote:> Pointer size on our target is 16-bits, and we have two 16-bit > registers that can be used only to hold pointers (indirect addresses). > > All operations on the target are 8-bit operations, so it takes two 8- > bit loads to load these pointer registers. > > We want LLVM to automatically expand all types to 8-bit values. > > The problem is that LLVM does not expand GlobalAddresses, which are > 16-bit values. > This in turn means that you have to specify a 16-bit register class, > and once you specify a 16-bit register class, LLVM does not further > expand 16-bit values. > > Any suggestions on how to model this into LLVM? > > TIA, > Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Sanjiv.Gupta at microchip.com
2008-Aug-07 16:45 UTC
[LLVMdev] Modeling 16-bit pointer registers for an 8-bit target
> > I don't think there is code in Legalizer to expand GlobalAddress. Butyou> can custom lower it. X86 custom lower GlobalAddress nodes for adifferent> reason. > > Evan >Hmmm...That means we have to make i16 as a legal type (since GlobalAddresses are 16-bits) and custom lower all 16-bit operations to 8-bit operations. I was thinking to take advantage of the already present ExpandOp infrastructure. -Sanjiv