[LLVMdev] Lowering operations to 8-bit!

Evan Cheng evan.cheng at apple.com
Wed Oct 10 21:00:59 PDT 2007 

On Oct 9, 2007, at 1:57 PM, Alireza.Moshtaghi at microchip.com wrote:

> 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 shadowed locations of each bank  
> that
> two of them act as index registers, and if you access (read/write) to
> the third register, the memory at address pointed to by the first two
> registers will be accessed (no banking in this mode)
>
> At first I created a class of 16-bit registers for the two special
> registers, but since LLVM only lowers to the largest register class  
> size
> (16-bit), it did not lower the rest of the operations to 8-bit.
> So I had to get rid of the 16-bit register class and now LLVM  
> lowers to
> 8-bit operations, but I have ended up with pointer size of 8-bit.
> Still I think there are tricks that I may be able to play by  
> customizing
> the GlobalAddress DAG and preloading the index registers. However,  
> first
> I would like to solicit your input and make sure that this is really
> what I want to do.

It's not clear to me how to express which "bank" to target in LLVM.  
The target independent LoadSDNode does have a SrcValue field. I  
suppose if you have a way to map the memory bank to this during  
selectiondag building you can then use it during instruction  
selection. Otherwise, like you said, you will have to reload the  
index registers somehow.

Sorry I can't be of much help. You are in new llvm territory here.

Evan

>
> Regards
> Ali.
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Evan Cheng
> Sent: Tuesday, October 09, 2007 1:24 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Lowering operations to 8-bit!
>
>
> 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 generated for a load:i16.
>>
>>
>> I have problem understanding this DAG in two places:
>>
>> 1)As you can see the UNDEF node is of type i8, however, we want it
>> to be
>> of type i16 because load is of type i16
>> As I trace llvm to see how it lowers, I see that it is basing the  
>> type
>> of UNDEF on the type of its address which is i8 :
>> SelectionDAG.cpp:2250
>> SDOperand Undef = getNode(ISD::UNDEF, Ptr.getValueType())
>> The question is why is it doing this? Shouldn't it use Ty instead of
>> Ptr.getValueType()?
>>
>> 2)Ok it is using an 8-bit GlobalAddress because I told it that
>> pointers
>> are 8-bit, however, what if my memory is bigger? I can cascade 2
>> registers and address more larger memory than only a 256-byte long.
>> The question is how can I make it generate GlobalAddress:i16 and  
>> later
>> break it down to two 8-bit values?
>
> Hrm. Looks like there is some confusion. What is the size of the
> addressable space? Setting ptr type to 8-bit means the size of the
> address is at most 256-byte. That seems awfully small. :-) Is this a
> 16-bit machine you are targeting? If so, please try setting pointer
> type to i16.
>
> Evan
>
>>
>>
>> Thanks.
>> A.
>>
>>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- 
>> bounces at cs.uiuc.edu]
>> On Behalf Of Evan Cheng
>> Sent: Wednesday, October 03, 2007 11:22 PM
>> To: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] Lowering operations to 8-bit!
>>
>>
>> On Oct 3, 2007, at 3:21 PM, Alireza.Moshtaghi at microchip.com wrote:
>>
>>> 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.
>>
>> If this works, please submit a patch. Otherwise please submit a bug
>> report with as much information as possible.
>>
>> Thanks,
>>
>> Evan
>>
>>>
>>> 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: LLVM Developers Mailing List
>>> Subject: Re: [LLVMdev] Lowering operations to 8-bit!
>>>
>>>
>>> On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote:
>>>
>>>> So does that mean that LLVM can't lower automatically to 8-bit
>>>> values?
>>>
>>> There is no inherent reason. LLVM should be able to lower to 8-bit
>>> values. It's probably a bug somewhere.
>>>
>>> In TargetLowering.h:
>>>
>>> bool isTypeLegal(MVT::ValueType VT) const {
>>>     return !MVT::isExtendedVT(VT) && RegClassForVT[VT] != 0;
>>>   }
>>>
>>> Is there a 16-bit register class?
>>>
>>>> I tried defining 8-bit pointers in the subtarget using "p:8:8:8"
>>>> but it
>>>> asserts at line 566 of TargetData.cpp in the default case of
>>>> TargetData::getIntPtrType()
>>>
>>> Dunno why it's like this. Can you add case 1: return Type::Int8Ty?
>>> Does it work / help?
>>>
>>> Evan
>>>
>>>>
>>>> Is it difficult to add 8-bit support?
>>>>
>>>> A.
>>>>
>>>> -----Original Message-----
>>>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-
>>>> bounces at cs.uiuc.edu]
>>>> On Behalf Of Chris Lattner
>>>> Sent: Friday, September 28, 2007 5:01 PM
>>>> To: LLVM Developers Mailing List
>>>> Subject: Re: [LLVMdev] Lowering operations to 8-bit!
>>>>
>>>>
>>>> On Sep 28, 2007, at 4:53 PM, <Alireza.Moshtaghi at microchip.com>
>>>> <Alireza.Moshtaghi at microchip.com> wrote:
>>>>
>>>>> ExpandOp is not called at all.
>>>>> In SelectionDAGLegalize::HandleOp() only the ValueType is
>>>>> considered in
>>>>> the switch statement to decide if it is legal or promote or  
>>>>> expand.
>>>>> As I trace back (correct me if I'm wrong) these values are set in
>>>>> TargetLowering::computeRegisterProperties() and it is based on the
>>>>> largest register class (in my case the smallest possible pointer
>>>>> size,
>>>>> 16-bit)
>>>>> So it reduces everything down to 16-bit and pretty much ignores  
>>>>> the
>>>>> fact
>>>>> that ADD of i16 is supposed to be expanded.
>>>>>
>>>>> Am I doing the right analysis?
>>>>
>>>> Yes.  It sounds like the codegen is assuming the pointer type is
>>>> valid in computeRegisterProperties or something.  Somehow i16 is
>>>> getting marked as legal.
>>>>
>>>> -Chris
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> <graph.ps>_______________________________________________
>> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list