[LLVMdev] More Back-End Porting Troubles

[Villmow, Micah]

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Fabian Scheler
> Sent: Wednesday, August 15, 2012 9:12 AM
> To: LLVM Developers Mailing List
> Subject: [LLVMdev] More Back-End Porting Troubles
> 
> Hi LLVM-Folks,
> 
> as mentioned in an earlier post
> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051677.html) I
> am currently working on a Back-End for the TriCore processor.
> Currently, I am struggling as LLVM could not select zext and load, for
> instance, so some of the testcases in test/CodeGen/Generic are not
> successfully compiled by my back-end.
> Furthermore, I am completely puzzled by the error messages generated.
> The testcase 'test/CodeGen/Generic/pr12507.ll' for instance yields:
> 
> LLVM ERROR: Cannot select: 0x229dbd0: i64,ch = load 0x226ee70,
> 0x229d8d0, 0x229d9d0<LD4[FixedStack-1](align=8), zext from i32>
> [ID=14]
>   0x229d8d0: i64 = FrameIndex<-1> [ORD=1] [ID=3]
>   0x229d9d0: i64 = undef [ORD=1] [ID=4]
[Villmow, Micah] This is a zero extending load and not just a normal load. Do you handle the pattern fragment zextload in your tablegen?
You can try to do setLoadExtAction(ISD::ZEXTLOAD, MVT::i64, Expand); in your ISelLowering constructor if you don't support this natively.

> 
> What exactly does this mean? OK, it means that some load instruction
> could not be selected. But why? Is the instruction not supported as it
> is (I doubt this as there are such instructions defined according with
> appropriate patterns)? Is the addressing mode node supported (how
> could I derive this information)? Is there a way how I can extract
> that information from these error messages in an "easy" manner?
> 
> My other problem is the zext instruction from i32 to i64. In
> principle, this is very easy on the TriCore. Zext the argument in the
> lower part of the 64bit register pair and write 0 to higher part.
> Finally, these parts are glued together using ISD::BUILD_PAIR.
> However, when I try to insert such nodes into the DAG within
> TriCoreTargetLowering, I run into an assertion:
> 
> llc:
> /home/scheler/git/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:704:
> void llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool,
> llvm::DenseMap<llvm::SDValue, unsigned int>&): Assertion
> `NumMIOperands >= II.getNumOperands() && NumMIOperands <=
> II.getNumOperands()+II.getNumImplicitDefs() && "#operands for dag node
> doesn't match .td file!"' failed.
> 
> Currently, I am not even able to find out which instruction is messed
> up here  (dumping the node via the dump-Method yields "<<Unknown
> Machine Node #65434>>"). Can I use "machine nodes" and "normal nodes"
> when lowering a specific instruction within the TargetLowering?
[Villmow, Micah] Have you tried using a tablegen pattern here? I find it is easier for simple conversions like this than using C++ code.
For example our backend does this with:
def uitoli64rr:Pat < (i64 (zext GPRI32:$src)), (LCREATEi64rr GPRI32:$src, (LOADCONSTi32 0)) >;
Where LCREATE is a machine instruction that does similar to ISD::BUILD_PAIR from two i32's and outputs a i64.

> 
> Any hints are highly welcome!
> 
> Ciao, Fabian
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev