[LLVMdev] PointerTypes with AddressSpace
Christopher Lamb
christopher.lamb at gmail.com
Wed Sep 12 20:46:10 PDT 2007
You may want to take a look at the Embedded C specification draft on
named memory spaces. Having the IR be able to support the standard
would probably be a "good thing".
See section 5.1
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
--
Christopher Lamb
On Sep 12, 2007, at 6:41 PM, <Alireza.Moshtaghi at microchip.com>
<Alireza.Moshtaghi at microchip.com> wrote:
> Chris,
> Extending LLVM IR to support PointerTypes that take an address
> space is
> what I was hoping to avoid. However, if we want to do things right,
> that
> is probably the way to go. Now that we got here, let me write some
> of my
> thoughts on this and solicit your input:
>
> --- 1) Syntax extension:
> In our existing compiler for 8-bit microcontrollers, we have
> introduced
> rom and ram qualifiers (with ram being the default one) that can be
> applied to any type for example:
> rom int a; //integer in program memory
> rom int *a; //ram pointer to integer in rom
> int * rom a; //rom pointer to integer in ram
> rom int * rom a; //rom pointer to integer in rom
> Is something similar to the above what you also envision?
>
> --- 2) Automatic pointers:
> This is what we don't have in our existing compiler, but many
> people are
> asking for it. Would it be possible in LLVM to treat pointers as
> general
> all the way to code generation, and then decide its Address Space
> based
> on the following criteria? (we should be able to do so in an LLVM pass
> because at code generation time we have the full view of the program)
> -- a) Address Space of the pointer is the Address Space of the
> variable
> eg: ptr = &var; //AddSp of ptr becomes AddSp of var
> -- b) Address Space of the pointer is the address Space of the pointer
> eg: ptr1 = ptr2; //AddSp of ptr1 becomes AddSp of ptr2
> -- c) Conflicts inside functions are not resolvable and should
> generate
> diagnostic.
> eg:
> void f(void){
> generalPtr = romPtr;
> //some code
> generalPtr = ramPtr; // non resolvable conflict
> }
> -- d) Conflicts at the function interface will spawn a new function
> eg:
> void inc(int *a){
> (*a)++;
> }
> void g(void){
> inc(romPointer); // this will spawn an f with rom pointer
> inc(ramPointer); // this will spawn an f with ram pointer
> }
>
> In the case of (2) we still need rom and ram qualifiers to declare
> variables in the intended Address Space, however the impact on the
> front
> end will probably be reduced.
> A combination of (1) and (2) would probably be ideal.
>
> Regards,
> Ali.
>
>
>
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Chris Lattner
> Sent: Wednesday, September 12, 2007 4:53 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] New to LLVM, Help needed
>
> 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 (functions or data in program memory)
>> At this moment, I am just using only one pointer size (16-bit)
>> just to
>> get things going; however, eventually I need to model the two pointer
>> types.
>> I was wondering if you have any suggestion as to how best I can model
>> this in LLVM.
>
> I don't think the code generator will need significant extension to
> support this: SDISel would just lower each to a different integer
> size.
>
> The place that will need extension is the LLVM IR itself. Here I
> think
> that we should expand PointerType to take some sort of address space
> identifier. This will allow the front-end to produce pointers of the
> right type and the codegen will be able to lower them to the right
> sized
>
> integer. This is a fairly invasive change, but should be relatively
> straight-forward to do.
>
> -Chris
>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-
>> bounces at cs.uiuc.edu]
>> On Behalf Of Chris Lattner
>> Sent: Wednesday, September 12, 2007 1:08 PM
>> To: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] New to LLVM, Help needed
>>
>> 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 file, is this right?
>>
>> If you aren't using 64-bit pointers, you should investigate where
>> this
>> node came from.
>>
>>> 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 couldn't find much about it in the
>>> PowerPC implementation either. The only thing is in the ctor of
>>> PPCTargetLowering there is setOperationAction(ISD::GlobalAddress,
>>> MVT::i32, Custom); and
>>>
>>> setOperationAction(ISD::GlobalAddress, MVT::i64, Custom);
>>> so I also added these two function calls to my ctor of
>>> PICxxTargetLowering. Nothing changed. I also tried "Expand" and
>> "Legal"
>>> instead of "Custom", still no progress. I'm sure I am missing some
>> thing
>>> here.
>>
>> You may be running into problems if the pointer type in the code
>> generator
>> isn't natively supported by your register file. We haven't hit a
> target
>>
>> like this yet, so you will likely have to expand LegalizeDAG to
>> handle
>> these cases.
>>
>> -Chris
>>
>>>
>>> From: llvmdev-bounces at cs.uiuc.edu
> [mailto:llvmdev-bounces at cs.uiuc.edu]
>>> On Behalf Of Evan Cheng
>>> Sent: Monday, September 10, 2007 10:29 AM
>>> To: LLVM Developers Mailing List
>>> Subject: Re: [LLVMdev] New to LLVM, Help needed
>>>
>>>
>>>
>>> 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 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,
>>> when it reaches the point where it wants to lower llvm IR to PICxx
>> DAG,
>>> it asserts in LegalizeDAG.cpp in ExpandOp() function after it hits
> the
>>> default case of switch(Node->getOpcode())
>>>
>>> Can someone please help me understand how am I ending up in the
>> default
>>> case?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> A.
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>>
>>>
>>
>> -Chris
>>
>>
>
> -Chris
>
> --
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> 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/20070912/3f2b2683/attachment.html>
More information about the llvm-dev
mailing list