thr3ads.net - llvm dev - [LLVMdev] Lowering operations to 8-bit! [Oct 2007]

If this information is useful, please help other people find it:
Share via:

Alireza.Moshtaghi at microchip.com

2007-Oct-03 22:21 UTC

[LLVMdev] Lowering operations to 8-bit!

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

Evan Cheng

2007-Oct-04 06:21 UTC

head link

[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

Alireza.Moshtaghi at microchip.com

2007-Oct-08 22:15 UTC

head link

[LLVMdev] Lowering operations to 8-bit!

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?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graph.ps
Type: application/postscript
Size: 14855 bytes
Desc: graph.ps
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20071008/21478a80/attachment.ps>

Possibly Parallel Threads

Search for more reasonably related threads

llvm dev - Oct 2007 - [LLVMdev] Lowering operations to 8-bit!

[LLVMdev] Lowering operations to 8-bit!

[LLVMdev] Lowering operations to 8-bit!

[LLVMdev] Lowering operations to 8-bit!

Possibly Parallel Threads