[LLVMdev] global type legalization?

[Bob Wilson]

Returning to an old discussion here....

On Aug 18, 2010, at 10:42 AM, Chris Lattner wrote:

> On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote:
>>> I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we're failing to handle.  I also do think that whole-function selection dags will solve a lot of grossness (e.g. much of codegen prepare) with a very clean model.
>> 
>> I'll take a look at Machine CSE and Machine Sink.  Where is the heuristic for tracking live-out vregs that you mention?  I'm definitely seeing a reextend of an already extended value.  Worse, the value is spilled and the zext is not folded into the reload.
> 
> The code I'm thinking of is in SelectionDAGISel::ComputeLiveOutVRegInfo

For the testcase I'm looking at, ComputeLiveOutVRegInfo does not help because it is called prior to selection when the load is an "any_ext" load.  It gets (arbitrarily) selected to LDRB, which zero-extends to 32 bits, but that's too late to affect the live-out info.

MachineCSE and MachineSink do not help because the first zero-extend is folded into the load (LDRB), so the redundant zero-extend (UXTB) does not appear to be a CSE.  In another case, the zero-extend is also folded into an add (UXTAB), which prevents the add from being selected to a better alternative (UXTAB does not allow immediate operands).

> 
>> For ARM and possibly other RISC-like targets, you simply can't define an i8 or i16 value -- those aren't legal types.  Since those values will always be extended at the point where they are defined, the code placement problem is straightforward: you always want to fold the extends into the def, as long as the value is always extended the same way (not mixed sign and zero extends).  Whole function selection DAGs would make that easy.
> 
> Right.  This is a bit trickier than you make it sound though, because an "i8" addition isn't neccessarily zero or sign extended when the add is done in a 32-bit register.

When you pointed this out earlier, I conceded that I was wrong, but on second thought, I'm surprised that llvm uses i8 adds.  Other compilers that I've worked on rely on the integral promotion rules for C/C++ to convert all integer arithmetic to the default "int" or "unsigned" type.  That tends to work out nicely for register-oriented targets.  Is there a reason why llvm does not take that approach?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100914/d6d7a9aa/attachment.html>