[llvm-commits] PATCH: Enhance the canonicalization of addressing-like operations for x86-64

[Chandler Carruth]

Greetings!

As I've been learning some of the innards of the x86 backend, I found
something rather surprising. A bunch of the patterns to match chains into
x86 addressing modes were working for 32-bits, but not for 64-bits. The
reason stemmed from the prevalence of 'zext' and 'sext' nodes between index
computations and the scales that come out of the GEP over the data type.
This would cause the chunk of code that tries to rotate (shift (and ...)
...) to (and (shift ...) ...) to give up because of an sext or zext node
between the two.

This same pattern also showed up in the code in the x86 backend that
matched the chains to addressing modes: they assumed (and (shl ...) ...) or
(and (srl ...) ...), and didn't check for an extend in between the two.

I've fixed both of these to look through extensions, and to re-extend the
transformed chains where necessary as a result. This allows enabling the
fold-and-shift test for x86-64; all the transforms continue to pass. One
thing I found was that some of the x86 code was relying on this
mis-canonicalization in order to form h-register extract patterns. I've
made that transform significantly more general in order to compensate; it
now should detect any time we can place an '0xFF' mask in the low byte by
shifting it back up in the addressing mode scale.

This patch is still pretty rough. I'd like more tests of the h-register
extraction on x86-64, I spotted much of the regressions there by inspection
rather than tests failing. I'd also like to do some performance analysis of
this because this is a non-trivial change to the canonicalized DAGs, but I
wanted some early feedback from folks. Does this make sense? Am I missing
something obvious that makes this unnecessary or harmful?

Also, the patch to DAGCombiner.cpp is pretty gross. I'd love any
suggestions on the ideal way to write that logic. Some of it is due to
cruft already present or poor naming and I'll clean that up in follow-up
patches once the functionality change is in place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120112/1a56f893/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 64bit-canonicalization.patch
Type: text/x-patch
Size: 13056 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120112/1a56f893/attachment.bin>