[LLVMdev] Lowering operations to 8-bit!

Tue Oct 9 13:57:55 PDT 2007

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.

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