Greetings!<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>