[LLVMdev] Turning on LegalizeTypes by default

[Alireza.Moshtaghi at microchip.com]

LegalizeTypes does add lots of good features, but at the end of the day
it lacked the essential part of our needs...
Part of the problem stems from the way that custom types are defined
which is not much different from LegalizeDAG.
Our target is 8 bit, but it also supports 16 bit pointers. The
setOperationAction(...) form of defining legal/illegal/custom types
indiscriminately tries to call the custom operation for all nodes if the
result is illegal, but for example for us, we want to keep some
operations 16 bit, while in some other situations the same is illegal,
forcing us to define our own target nodes and completely work our way
around llvm nodes for load/store.
I think this part of the work can benefit from tablegen to check for
patterns of SDNode instead of just checking for particular operation and
its type, but I haven't had time to sit down and think how....

Regardless, LegalizeTypes is a great improvement.

Thanks
Ali

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On
> Behalf Of Duncan Sands
> Sent: Sunday, October 26, 2008 1:03 AM
> To: LLVM Developers Mailing List
> Subject: [LLVMdev] Turning on LegalizeTypes by default
> 
> Hi all, I plan to turn on the new type legalization infrastructure
> "LegalizeTypes" by default tomorrow.  This is a
redesign/reimplementation
> of the logic currently in LegalizeDAG that turns (for example) 64 bit
> arithmetic on a 32 bit machine into a series of 32 bit operations.  As
> well
> as being a cleaner design, it also supports code generation for
arbitrary
> precision integers such as i123.
> 
> This is likely to cause some breakage since I mostly only added
support
> for
> operations for which I had a testcase (by running "make check" or
> compiling
> the testsuite etc), and I was only able to test on x86 linux (32 and
64
> bit).
> However it is usually easy to add support for missing operations, so I
> expect
> all such problems to be fixed promptly.
> 
> LegalizeTypes was turned on once before.  It broke llvm-gcc bootstrap
on
> darwin at a time when, it seems, such breakage was particularly
annoying,
> and was turned off again.  As a result it has been sitting forgotten
in
> the
> tree, bitrotting as fixes and improvements were made only to
LegalizeDAG.
> I don't want this to happen again.
> 
> So please: if LegalizeTypes breaks something, send me a bitcode
testcase
> rather than turning LegalizeTypes off again.  With a major change like
> this
> there is bound to be some pain, but I don't expect it to last more
than a
> week or two.
> 
> Once LegalizeTypes has stabilized, I plan to progressively delete type
> legalization functionality from LegalizeDAG, checking that
LegalizeTypes
> has the same functionality as I go, and adding it if not.
> 
> Testsuite results are as follows:
> 
> (a) "make check" has two failures:
>   ARM/cse-libcalls.ll - this is because of a bug in UpdateNodeOperands
> which does not do CSE on calls correctly.  The question here is how
best
> to fix this while minimizing code duplication.  This will doubtless be
> fixed soon.
>   PowerPC/vec_spat.ll (@splat_h) - here code got slightly worse.  The
> problem here is that LegalizeDAG "cheats": it constructs a
BUILD_VECTOR
> where the type of the operands doesn't match the vector element type
(this
> is supposed to be illegal), while LegalizeTypes correctly constructs a
> BUILD_VECTOR where the operand type is equal to the vector element
type,
> but then the PPC custom code doesn't handle this optimally.  Two
> solutions:
> decide that in fact
>   v8i16 = BUILD_VECTOR(i32, i32, ..., i32)
> is legal and modify LegalizeTypes to take advantage of this; or
improve
> the PPC so it better handles the code coming out of LegalizeTypes.
> 
> (b) llvm-gcc builds with languages Ada, C, C++, Fortran, Objc and
Obj-c++
> on x86-32-linux, and bootstraps with languages C, C++ and Fortran on
> x86-64-linux.  This is the same as without LegalizeTypes.
> 
> (c) No additional failures in the full testsuite for x86 linux (32 and
> 64 bit).
> 
> (d) No additional failures in the Ada ACATS testsuite (x86-32 linux).
> 
> Ciao,
> 
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev