Jason Kim
2012-Feb-17 05:59 UTC
[LLVMdev] 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, 0x1e4c030<Mem: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, 0x22c10b0<Mem: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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120216/5bc643fe/attachment.html>