[llvm-commits] [llvm-gcc] Cast Fix

[Reid Spencer]

On Mon, 2006-12-18 at 14:50 -0800, Chris Lattner wrote:
> On Dec 18, 2006, at 11:25 AM, Reid Spencer wrote:
> 
> > All,
> >
> > This patch is needed to update llvm-gcc to avoid inferred casts as  
> > LLVM
> > no longer supports them.  This patch is sufficient for getting llvm- 
> > gcc
> > to compile/work for an X86 target.
> >
> > This cast does not include needed changes to gcc/config/rs6000/ 
> > rs6000.h
> > Those changes will be sent in a subsequent patch.
> 
> Jim already applied this (thx Jim!), so this is just an FYI:
> 
> You're basing all of the checks here on whether or not the LLVM types  
> are signed.  I understand that this is the most expedient way to get  
> stuff working in the short term, but this isn't going to work long  
> term, as the ->isSigned() methods are not going to exist any more.   
> You should eventually migrate these to using TREE_UNSIGNED and  
> similar macros, checking properties from the GCC trees.

Yes, I understand. I was solely working towards a) fixing the breakage
and b) retaining current functionality. There were a lot of changes to
make in a short time to get llvm-gcc compiling again. Many of these need
some deep analysis and rather than delay the patch, I took this route.

> 
> Further, the casts in i386.h that call getCastOpcode, should be  
> updated to use the appropriate cast.  However, I'm not sure what they  
> are, you can work with Evan to figure them out.

I tried a few of them as specific casts and it broke many things which
is just an indication that I didn't fully analyze the set of types that
can be passed in. The places were getCastOpcode will remain in use are
those places where the type could be anything or close to anything (e.g.
function arguments and returns).  These also will be reviewed in more
detail as I continue to remove signlessness.

FYI: my strategy here is to work from the bottom up. With the last few
patches VMCore contains only one isSigned() call (in AsmWriter). I'm
currently working on a fix for that. Once VMCore is clean, I'll move on
to other libraries and on up the chain, removing getCastOpcode,
isSigned, isUnsigned, getSignedVersion, getUnsignedVersion, etc.

This will take a while, many of the remaining cases require some
significant modifications in order to figure out if the value is signed
or not.  Speaking of which, I was thinking of adding a method to
Instruction, isSignedOperand(unsigned) which recursively figures out if
the operand can be signed. Consider a bunch of arithmetic based on a
ZExt or SExt, something like:

bool %func(sbyte %a) {
   %b = zext sbyte %a to short
   %c = sext sbyte %a to ushort
   %d = add short %b, %b
   %e = add ushort %c, %c
   %f = bitcast short %d to ushort
   %ret = call bool %doit(ushort %f, short %d)
   ret bool %ret
}

In such a function the declared types are meaningless. %b is unsigned. %
c is signed. When it comes time to check the parameters to %doit, I need
to know that. About the only way I can think of is to write a function
on Instruction that recursively calls itself following the use chain
until it finds something that is concretely signed or not. Even this
might not help. Suppose the zext and sext weren't in this function. I
can't statically determine the signedness of sbyte %a which might be
signed or not.

Thoughts?


> 
> -Chris