ARM/Thumb2/ISEL Need help tracing down a failing match: (HOW?)

Hi, after perusing through llc -debug output and stepping through the ARMGenDAGIsel.inc in the debugger, I would greatly like some help in tracking down a failing match to a pattern I specified:

First, here is a snippet of a successful match (done in ARM mode)

ISEL: Starting pattern match on root node: 0x1e7adf0: i32,ch = load 0x1e4c030, 0x1e78210, 0x1e78310<LD4[ConstantPool]> [ID=10]

Initial Opcode index to 24435

Morphed node: 0x1e7adf0: i32,ch = LDRi12 0x1e78210, 0x1e78010, 0x1e7aef0, 0x1e7b0f0, 0x1e4c030Mem:LD4[ConstantPool]

ISEL: Match complete!
ISEL: Starting pattern match on root node: 0x1e78210: i32 = ARMISD::Wrapper 0x1e77f10 [ID=9]

Initial Opcode index to 49796
OpcodeSwitch from 49799 to 49891
Skipped scope entry (due to false predicate) at index 49896, continuing at 49914
Morphed node: 0x1e78210: i32 = MOVi32imm 0x1e77f10

ISEL: Match complete!

Here is the failing case in Thumb2 mode

ISEL: Starting pattern match on root node: 0x22f0f10: i32,ch = load 0x22c10b0, 0x22ee330, 0x22ee430<LD4[ConstantPool]> [ID=10]

Initial Opcode index to 24668
Match failed at index 24684

Continuing at 26993
Skipped scope entry (due to false predicate) at index 27018, continuing at 27037
Morphed node: 0x22f0f10: i32,ch = t2LDRpci 0x22ee030, 0x22f1010, 0x22f1210, 0x22c10b0Mem:LD4[ConstantPool]

ISEL: Match complete!

The logic here (already implemented and working in ARM mode) is to turn all constant island entries into .rodata (i.e. skip constant island pass).
In the thumb2 case, the expected match- ARMISD::Wrapper, which is supposed to morphed to a t2MOVi32imm never happens:

I’ve placed all the expected patterns to match tconstpool and (hopefully) turned on the correct Requires flag in the ARMInstrThumb2.td in all the places where ARMWrapper tconstpool occurs.

However, the expected match does not occur and I am at a loss to explain it.

I suppose there are several things that could be broken:

  1. There is a bug in the patterns I specified in the .td file
  2. There is some hardcoded glue in ARMInstrThumb2.td that prevents the expected match from happening (perhaps something to do with ‘pci’ pattern in multiclass T2I_ld ??)
  3. There is some other glue that prevents the pattern from matching (perhaps in ARMISelLowering - which does have custom code…)

Assuming that the case is the first or second, what is the best way to associate the table information in ARMGenDAGISel.inc to the entries in the .td file? That is, while stepping through SelectCodeCommon(), I am having a difficult time associating the MatchIndex and the associated MatchTable to the entries in the .td… Any pointers or help would be greatly appreciated.

Thank you!
-jason