similar to: [LLVMdev] Modeling 16-bit pointer registers for an 8-bit target

> > 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 > 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

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

All the sub methods called inside ExpandIntegerOperand like ExpandInOp_STORE etc have access to the expanded operands map. Why they aren't passed to target LowerOperation? A target may also want to use the already expanded Lo and Hi parts. - Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

More information on this... still not working When I build the project for Debug and run the program, the following message is printed before assert. NODE: 0x937bac8: i64 = GlobalAddress <i32* @var> 0 I guess it is expecting that GlobalAddress be legalized before reaching ExpandOp(). I haven't implemented anything for ISD::GlobalAddress, and that may explain it, however, I

Hi, I have started to write an llvm backend for one of our microcontrollers (PICxx). I started studying the framework of PowerPc backend of llvm and decided to start by following that framework. Now I have most of the classes and Tblgen files written for a very basic hypothetical microcontroller with very few instructions. The project builds and the llc recognizes the new processor, however,

Every GlobalAddress has a GlobalValue, Every GlobalValue is a PointerType, Every PointerType has an AddressSpace. So is it ok to add a method getAddressSpace in GlobalAddressSDNode class itself? Currently we have to do GSDN->getGlobal()->getType()->getAddressSpace(). - Sanjiv

Thank you Chris, I had the pointer size wrong. I fixed it and now it passes that point as expected :) which takes me to a second question: The processor that I am working on is 8-bit and has Harvard architecture; this implies different pointer types (sizes) to objects in data memory or program memory (functions or data in program memory) At this moment, I am just using only one pointer size

I am trying to verify the generated DAG after converting from llvm to DAG, however I'm not sure if this is correct or not. Here is the situation: In order to get LLVM to lower to 8-bit I have to define only 8-bit registers and the pointer size also to be 8-bit. Doing so, the attached DAG is generated for a load:i16. I have problem understanding this DAG in two places: 1)As you can see the

On Tue, Sep 30, 2008 at 9:48 AM, <Sanjiv.Gupta at microchip.com> wrote: > All the sub methods called inside ExpandIntegerOperand like ExpandInOp_STORE > etc have access to the expanded operands map. > > Why they aren't passed to target LowerOperation? A target may also want to > use the already expanded Lo and Hi parts. You don't really need access to the map; just

On Thu, 2008-10-02 at 08:53 -0700, Chris Lattner wrote: > On Oct 2, 2008, at 8:38 AM, Eli Friedman wrote: > > > On Thu, Oct 2, 2008 at 7:34 AM, Evan Cheng <evan.cheng at apple.com> > > wrote: > >> > >> On Oct 2, 2008, at 2:01 AM, sanjiv gupta wrote: > >> > >>> > >>>> > >>>> So you have a i16 register

>I am assuming a 16-bit value will be stored in a pair of 8-bit > registers? One related question is how to make sure that the correct register pair is allocated to the16-bit quantity when using two 8-bit operations. In other words, how we can make sure that the 16-bit pointer is stored into [AH, AL] and not in [AH, BL] ? i.e. GR8 = [ AH, BH, AL, BL]; GR16 = [AX, BX] ; // AX, BX

On Tue, 11 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > More information on this... still not working > When I build the project for Debug and run the program, the following > message is printed before assert. > > NODE: 0x937bac8: i64 = GlobalAddress <i32* @var> 0 This implies that your target uses 64-bit pointers, but that it doesn't have a 64-bit register

Please do a debug build and run it under gdb. Let us know where it is asserting and what it is asserting on so we can help you. Evan On Sep 7, 2007, at 4:50 PM, Alireza.Moshtaghi at microchip.com wrote: > Hi, > I have started to write an llvm backend for one of our > microcontrollers (PICxx). I started studying the framework of > PowerPc backend of llvm and decided to start by

> >>>> You can try just marking all i16 operations, other than load and > >>>> store, as "expand". Would that work? > >>> > >>> Won't work; LLVM expects at least some basic operations, like add, > >>> to > >>> be legal in legal register types. > >> > >> That sounds like a bug, not a

On Wed, 12 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > Thank you Chris, > I had the pointer size wrong. I fixed it and now it passes that point as > expected :) which takes me to a second question: cool > The processor that I am working on is 8-bit and has Harvard > architecture; this implies different pointer types (sizes) to objects in > data memory or program memory

On Oct 8, 2007, at 3:15 PM, Alireza.Moshtaghi at microchip.com wrote: > I am trying to verify the generated DAG after converting from llvm to > DAG, however I'm not sure if this is correct or not. > Here is the situation: > In order to get LLVM to lower to 8-bit I have to define only 8-bit > registers and the pointer size also to be 8-bit. > Doing so, the attached DAG is

Evan, The machine is 8 bit, and of course all registers are 8-bit too. Memory access on this machine is a bit different. The memory is banked into banks of 256-byte, and you can select the active bank using a bank select register. All instructions can access the memory with an 8-bit operand, so in that sense the address space can be viewed as 256-byte long. On the other hand, there are three

In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some other physical register which may be holding a live value used somewhere else. How do I make regalloc aware so that it saves the value before storeRegToStackSlot and make it available again at the point of earlier use? TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

Thank you Evan, I added the return Type::Int8Ty to the switch statement to get it to work. I don't know if this can have other consequences, I haven't yet verified if the generated Legalized DAG is correct though. A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 3:23 PM To:

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Bill Wendling > Sent: Friday, September 19, 2008 4:38 AM > > On Thu, Sep 18, 2008 at 7:12 AM, <Sachin.Punyani at microchip.com> wrote: > > What changes would be required in LLVM to support illegal pointer type? > > > Hi Sachin, >