[LLVMdev] Turning on LegalizeTypes by default

Duncan Sands baldrick at free.fr
Sun Oct 26 01:03:00 PDT 2008

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).



More information about the llvm-dev mailing list