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

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?

Ali.

-----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 1:55 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Lowering operations to 8-bit!


On Sep 28, 2007, at 1:10 PM, <Alireza.Moshtaghi at microchip.com>  
<Alireza.Moshtaghi at microchip.com> wrote:
> Attached please find the gdb backtrace dump and the postscript file of
> the DAG right before assertion.
> The red Node is the current Node in LegalizeOp()
Okay, this is the problem.  LegalizeOp should only be called on a  
node if the VT is valid for the target.  In this case, ExpandOp  
should have been called to split the register up.  I'd suggest going  
up the stack to figure out who called LegalizeOp instead of ExpandOp.
> Here is my code in the formalizing arguments (copied ISD::MERGE_VALUES
> from PowerPC implementation, not sure if it is really needed)
MergeValues is required because the FORMAL_ARGUMENTs node returns one  
value for each argument input to the function, and also a chain  
value.  These have to match up correctly.

-Chris
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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

So does that mean that LLVM can't lower automatically to 8-bit values?
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()

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