search for: gettypetotransformto

...a reason why it is not too obvious how to handle > f32->f64 promotion and later f64->i64 expansion on targets that > support > only f64 soft-floats. > > Chris Lattner wrote: >> That would be recursively expanded to i64, then to 2x i32 if needed. > > I tried to set getTypeToTransformTo(f32) to return f64, even when f64 > is illegal type. But this recursive expansion does not take place with > the current legalizer implementation. Currently, it is assumed that > the > result of getTypeToTransformTo() is a legal type. For example, > CreateRegForValue tries to crea...

...> types. Yes. And this is also a reason why it is not too obvious how to handle f32->f64 promotion and later f64->i64 expansion on targets that support only f64 soft-floats. Chris Lattner wrote: >That would be recursively expanded to i64, then to 2x i32 if needed. I tried to set getTypeToTransformTo(f32) to return f64, even when f64 is illegal type. But this recursive expansion does not take place with the current legalizer implementation. Currently, it is assumed that the result of getTypeToTransformTo() is a legal type. For example, CreateRegForValue tries to create a register of such a pro...

> >> d) Would it be possible with current implementation of soft-float >> support to map f32/f64 to integer types smaller than i32, e.g. to >> i16? >> I have the impression that it is not necessarily the case, since it >> would require that f64 is split into 4 parts. > > Yes, this should be fine. > >> This question is more about a theoretical

...dle > > f32->f64 promotion and later f64->i64 expansion on targets that > > support > > only f64 soft-floats. > > > > Chris Lattner wrote: > >> That would be recursively expanded to i64, then to 2x i32 if > needed. > > > > I tried to set getTypeToTransformTo(f32) to return f64, even when > f64 > > is illegal type. But this recursive expansion does not take place > with > > the current legalizer implementation. Currently, it is assumed that > > > the > > result of getTypeToTransformTo() is a legal type. For example, &...

...br label %return return: ; preds = %entry %2 = load i32* %retval ; <i32> [#uses=1] ret i32 %2 } If I make "type" long long, it works OK. I tracked the problem down to this: In the beginning of SelectionDAGLegalize::ExpandOp there is a call to getTypeToTransformTo to get the type of the expanded parts. In the case of i64, it returns i32 (as expected). In the case of f64, it returns i64. The i64 causes the assert later in LegalizeOP(Hi). Looking at getTypeToTransformTo it seems that it is doing what it is supposed to do, at least according to the comments....

...64 promotion and later f64->i64 expansion on targets that >>> support >>> only f64 soft-floats. >>> >>> Chris Lattner wrote: >>>> That would be recursively expanded to i64, then to 2x i32 if >> needed. >>> >>> I tried to set getTypeToTransformTo(f32) to return f64, even when >> f64 >>> is illegal type. But this recursive expansion does not take place >> with >>> the current legalizer implementation. Currently, it is assumed that >> >>> the >>> result of getTypeToTransformTo() is a lega...

Hello, Everyone > On this specific case, IIRC, MinGW chokes if asmprinter is not on the > list of components. This may be another consequence of the malfunctoning > of llvm-config/GenLibDeps.pl on MinGW/MSYS. This works for me without any problems on mingw32. What are the problems you're seeing? -- WBR, Anton Korobeynikov

...ed to // at least 32-bit. But this is not necessary for non-C calling conventions. if (MVT::isInteger(RetOp.getValueType()) && RetOp.getValueType() < MVT::i64) { MVT::ValueType TmpVT; if (TLI.getTypeAction(MVT::i32) == TargetLowering::Promote) TmpVT = TLI.getTypeToTransformTo(MVT::i32); else TmpVT = MVT::i32; This is wrong in at least two ways: 1. First it encodes C semantics in the backend, making other language front-ends difficult. The comment indicates that this is to be fixed. 2. But it even gets the C semantics wrong, the promotion is to &quo...

...t possible, f32 should be always promoted first to f64 and then an f64 operation should be applied. I see a small problem here with the current code, since f32 should be promoted to the illegal type f64. It might require some special-case handling eventually. For example, what should be the result getTypeToTransformTo(f32)? On the one hand, it is f64. On the other hand it is illegal. b) LLVM currently uses hard-wired library function names for FP libcalls (and ALL other libcalls as well). It would be nice if they would be customizable, since some targets (e.g. some embedded systems) hav...

...llc 0x0000000000ee488d 2 libpthread.so.0 0x00007f988a8f8e90 3 libc.so.6 0x00007f9889c022f5 gsignal + 53 4 libc.so.6 0x00007f9889c03b20 abort + 384 5 libc.so.6 0x00007f9889bfb2fa __assert_fail + 234 6 llc 0x0000000000640421 llvm::TargetLowering::getTypeToTransformTo(llvm::LLVMContext&, llvm::EVT) const + 977 7 llc 0x0000000000be1aff 8 llc 0x0000000000be6e11 9 llc 0x0000000000badf80 10 llc 0x0000000000bae9d8 llvm::SelectionDAG::LegalizeTypes() + 824 11 llc 0x0000000000b71c14 llvm::Selection...

...ly less efficient code for targets that have both) but we should support this. > I see a small problem here with the current code, since f32 should be > promoted to the illegal type f64. It might require some special-case > handling eventually. For example, what should be the result > getTypeToTransformTo(f32)? On the one hand, it is f64. On the other > hand it is illegal. I think getTypeToTransformTo(f32) should return f64. That would be recursively expanded to i64, then to 2x i32 if needed. I haven't looked at the mechanics required to get this working, but it shouldn't be too ugly...

...t. But this is not necessary for non-C calling conventions. > if (MVT::isInteger(RetOp.getValueType()) && > RetOp.getValueType() < MVT::i64) { > MVT::ValueType TmpVT; > if (TLI.getTypeAction(MVT::i32) == TargetLowering::Promote) > TmpVT = TLI.getTypeToTransformTo(MVT::i32); > else > TmpVT = MVT::i32; > > This is wrong in at least two ways: > 1. First it encodes C semantics in the backend, making other language > front-ends difficult. The comment indicates that this is to be fixed. > 2. But it even gets the C semant...

...T > VT && MVT::isInteger(NVT) == MVT::isInteger(VT) && "Cannot promote to smaller type!"' failed. The corresponding code is the following: SDOperand SelectionDAGLegalize::PromoteOp(SDOperand Op) { MVT::ValueType VT = Op.getValueType(); MVT::ValueType NVT = TLI.getTypeToTransformTo(VT); assert(getTypeAction(VT) == Promote && "Caller should expand or legalize operands that are not promotable!"); assert(NVT > VT && MVT::isInteger(NVT) == MVT::isInteger(VT) && "Cannot promote to smaller type!"); The assert fai...

...0ee488d > 2 libpthread.so.0 0x00007f988a8f8e90 > 3 libc.so.6 0x00007f9889c022f5 gsignal + 53 > 4 libc.so.6 0x00007f9889c03b20 abort + 384 > 5 libc.so.6 0x00007f9889bfb2fa __assert_fail + 234 > 6 llc 0x0000000000640421 > llvm::TargetLowering::getTypeToTransformTo(llvm::LLVMContext&, > llvm::EVT) const + 977 > 7 llc 0x0000000000be1aff > 8 llc 0x0000000000be6e11 > 9 llc 0x0000000000badf80 > 10 llc 0x0000000000bae9d8 > llvm::SelectionDAG::LegalizeTypes() + 824 > 11 llc...

...submitting a patch? Thanks, Javier [Original] /// ExpandShiftWithUnknownAmountBit - Fully general expansion of integer shift /// of any size. bool DAGTypeLegalizer:: ExpandShiftWithUnknownAmountBit(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue Amt = N->getOperand(1); EVT NVT = TLI.getTypeToTransformTo(*DAG.getContext(), N->getValueType(0)); EVT ShTy = Amt.getValueType(); unsigned NVTBits = NVT.getSizeInBits(); assert(isPowerOf2_32(NVTBits) && "Expanded integer type size not a power of two!"); DebugLoc dl = N->getDebugLoc(); // Get the incoming operand...

...d also in > SelectioNDAGISel.cpp should be altered. I tried for example to modify > the computeRegisterProperties to tell that f64 is actually represented > as 2xi32. Good, this is the first step. Your goal is to get TLI.getTypeAction(MVT::f64) to return 'expand' and to get TLI.getTypeToTransformTo(f64) to return i32. > I also added some code into the function > FunctionLoweringInfo::CreateRegForValue for allocating this pair of i32 > regs for f64 values. But it does not seem to help. Ok. > From what I can see, the problem is that emitNode() still looks at the > machine inst...

Hi, I still have some questions about FP emulation for my embedded target. To recap a bit: My target only has integer registers and no hardware support for FP. FP is supported only via emulation. Only f64 is supported. All FP operations should be implemented to use i32 registers. Based on the fruitful discussions on this list I was already able to implement mapping of the FP operations to

Hi Javier, On 05/03/12 18:10, Martinez, Javier E wrote: > I still haven’t received any feedback on me adding support for widening of > stores. Is there interest? did you try LLVM 3.0? Ciao, Duncan. > > Thanks, > > Javier > > *From:*llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Martinez, Javier E > *Sent:* Wednesday,

...ld be altered. I tried for example to > modify > > the computeRegisterProperties to tell that f64 is actually > represented > > as 2xi32. > > Good, this is the first step. Your goal is to get > TLI.getTypeAction(MVT::f64) to return 'expand' and to get > TLI.getTypeToTransformTo(f64) to return i32. After I sent a mail to the mailing list, I figured out that I need to do this, so I added exactly what you describe and it helped. > > I also added some code into the function > > FunctionLoweringInfo::CreateRegForValue for allocating this pair of > i32 regs f...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more