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
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
(d) No additional failures in the Ada ACATS testsuite (x86-32 linux).