search for: getregistertype

...ectionDAGLegalize::PromoteNode() yet. DAGTypeLegalizer > is used to legalize "non-legal" types regardless of the operation > (need confirmation). Thanks! That makes sense, and looking more closely at the PromoteIntRes_VAARG code, it finds the type to which to promote by calling TLI.getRegisterType, which won't work in this case. This should not be difficult to fix. -Hal > > Ivan > > > > > Thanks again, > > Hal > > -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory 1-630-252-0023 hfinkel at anl.gov

...0x00000001004424cd llvm::DenseMap<llvm::SDValue, llvm::SDValue, llvm::DenseMapInfo<llvm::SDValue>, llvm::DenseMapInfo<llvm::SDValue> >::insert(std::pair<llvm::SDValue, llvm::SDValue> const&) + 54509 7 llc 0x0000000100429633 llvm::TargetLowering::getRegisterType(llvm::LLVMContext&, llvm::EVT) const + 208419 8 llc 0x000000010042aab6 llvm::TargetLowering::getRegisterType(llvm::LLVMContext&, llvm::EVT) const + 213670 9 llc 0x00000001004f9474 llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +...

...0x00000001004424cd llvm::DenseMap<llvm::SDValue, llvm::SDValue, llvm::DenseMapInfo<llvm::SDValue>, llvm::DenseMapInfo<llvm::SDValue> >::insert(std::pair<llvm::SDValue, llvm::SDValue> const&) + 54509 7 llc 0x0000000100429633 llvm::TargetLowering::getRegisterType(llvm::LLVMContext&, llvm::EVT) const + 208419 8 llc 0x000000010042aab6 llvm::TargetLowering::getRegisterType(llvm::LLVMContext&, llvm::EVT) const + 213670 9 llc 0x00000001004f9474 llvm::TargetLowering::getNumRegisters(llvm::LLVMContext&, llvm::EVT) const +...

...moteNode() yet. DAGTypeLegalizer >> is used to legalize "non-legal" types regardless of the operation >> (need confirmation). > Thanks! That makes sense, and looking more closely at the > PromoteIntRes_VAARG code, it finds the type to which to promote by > calling TLI.getRegisterType, which won't work in this case. This should > not be difficult to fix. I think that PromoteIntRes_VAARG won't even get called if VAARG has a legal type, which is the case for i32 in PPC for example. If you want to promote VAARG nodes with a legal type to i64, you should rather add an...

...least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind != ISD::ANY_EXTEND && VT.isInteger()) { EVT MinVT = TLI.getRegisterType(*DAG.getContext(), MVT::i32); if (VT.bitsLT(MinVT)) VT = MinVT; } There have been a few discussions about this snippet on llvmdev in the past[1][2][3], and there seems to be a general consensus that the responsibility for promoting to the 'int' type should be...

[snip] > The ABI boundary lowering requires types to be broken down further into > 'legal types' that can be mapped to registers. The secondary breakdown is > currently handled by TargetLowering::LowerCallTo() calling > getRegisterType() and getNumRegisters(). Most ABIs are defined in terms > of C types, not LLVM IR types, so there is a close connection between the C > frontend and the ABI lowering code in the instruction selector. It would be > a good idea to have the ABI lowering code work independently of the type &gt...

...g a problem in SelectionDAGBuild::visitRet(), mainly: MVT VT = ValueVTs[j]; // FIXME: C calling convention requires the return type to be promoted to // at least 32-bit. But this is not necessary for non-C calling // conventions. if (VT.isInteger()) { MVT MinVT = TLI.getRegisterType(MVT::i32); if (VT.bitsLT(MinVT)) VT = MinVT; } This is occurring when VT is a 16bit vector type,<2x i8>. LLVM is then changing it to be a 32bit type and it asserts in : getCopyToParts(DAG, SDValue(RetOp.getNode(), RetOp.getResNo() + j), &...

...ut this is not necessary for non-C calling > // conventions. The frontend should mark functions whose return values > // require promoting with signext or zeroext attributes. > if (ExtendKind != ISD::ANY_EXTEND && VT.isInteger()) { > EVT MinVT = TLI.getRegisterType(*DAG.getContext(), MVT::i32); > if (VT.bitsLT(MinVT)) > VT = MinVT; > } > > There have been a few discussions about this snippet on llvmdev in the > past[1][2][3], and there seems to be a general consensus that the > responsibility for promoting to t...

Hi Finkel, Le 23/03/2012 05:50, Hal Finkel a écrit : > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > currently has a problem handling integer types smaller than 64 bits. > This is because the ABI specifies that these types are zero-extended to > 64 bits on the stack and the default logic provided in LegalizeDAG does > not use that convention. Specifically, for

The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems currently has a problem handling integer types smaller than 64 bits. This is because the ABI specifies that these types are zero-extended to 64 bits on the stack and the default logic provided in LegalizeDAG does not use that convention. Specifically, for these targets we have: setOperationAction(ISD::VAARG, MVT::Other, Expand);

...l pass (or a parameter for this one) that lowers pointer operations to integers. > The ABI boundary lowering requires types to be broken down further into 'legal types' that can be mapped to registers. The secondary breakdown is currently handled by TargetLowering::LowerCallTo() calling getRegisterType() and getNumRegisters(). Most ABIs are defined in terms of C types, not LLVM IR types, so there is a close connection between the C frontend and the ABI lowering code in the instruction selector. It would be a good idea to have the ABI lowering code work independently of the type system used during...

...ister class. EVTs are all the integer, floating point, and vector types from LLVM IR. The ABI boundary lowering requires types to be broken down further into 'legal types' that can be mapped to registers. The secondary breakdown is currently handled by TargetLowering::LowerCallTo() calling getRegisterType() and getNumRegisters(). Most ABIs are defined in terms of C types, not LLVM IR types, so there is a close connection between the C frontend and the ABI lowering code in the instruction selector. It would be a good idea to have the ABI lowering code work independently of the type system used during...