similar to: [LLVMdev] Cannot Select ConstantFP on x86

On Sep 24, 2008, at 5:11 PM, David Greene wrote: > I just ran into this today with x86-64: > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > of the > constant 1 and hapilly folds it into a ConstantFP<1>. ISel then > blows up > because there's no pattern for it. > >

On Thursday 25 September 2008 19:12, Chris Lattner wrote: > On Sep 24, 2008, at 5:11 PM, David Greene wrote: > > I just ran into this today with x86-64: > > > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > > of the > > constant 1 and hapilly folds it into a

What is the proper way to get the bit pattern associated with a ConstantFP? The 32 bit pattern if MVT::f32 or pair of 32 bit patterns with MVT::f64 ? Tia. Reed

1. My configuration: OS: ubuntu11.04, CPU: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz llvm: llvm-2.8 2. My running environment: ~#llvm-gcc -DCOMPDATE="today" -DCFLAGS="" -DHOSTNAME="thishost" -DNeedFunctionPrototypes=1 -DSASR -DPROBES=8 -O3 -emit-llvm /home/qali/Develop/Benchmark/MultipleSource/FreeBench/distray/distray.c -o

On Sep 5, 2007, at 2:21 PM, Chuck Rose III wrote: > Hola LLVMers, > > > > I’m getting a crash when using ConstantFP::get. > > > > I can repro it by adding one line to the Fibonacci example program: > > > > int main(int argc, char **argv) { > > int n = argc > 1 ? atol(argv[1]) : 24; > > > > // Create some module to put our function

Hola LLVMers, I'm getting a crash when using ConstantFP::get. I can repro it by adding one line to the Fibonacci example program: int main(int argc, char **argv) { int n = argc > 1 ? atol(argv[1]) : 24; // Create some module to put our function into it. Module *M = new Module("test"); // We are about to create the "fib" function: Function

----- Original Message ----- > Hi, > > I noticed that ConstantFP::get automatically returns the > appropriately > types Constant depending on the LLVM type passed in (i.e. if called > with a vector, it returns a splat vector with the given constant). > > Is there any simple way to do the inverse of this function? i.e., > given a llvm::Value, check whether it is either

Hola Dale, I spent some time walking through what's going on with a friend of mine from VStudio. Category is given 2 bits in the APFloat class definition. It's sign extending the enum value for the comparisons when it loads it out of the class, so the 2 becomes a -2 and the comparison fails. He sent me a piece of code which I might be able to use to force the issue. I'll update

Hi, I want to create a double constant from a float constant, here's my code: auto* constFloat1 = static_cast<llvm::ConstantFP*>(llvm::ConstantFP::get(llvm::Type::getFloatTy(context), 3.1)); assert(constFloat1->getType() == llvm::Type::getFloatTy(context)); auto* constFloat2 = llvm::ConstantFP::get(llvm::Type::getDoubleTy(context), constFloat1->getValueAPF());

It's in debug. I'm having a look at the assembler it's producing right now and it's definitely a little odd for what should be a simple assignment in zeroSignificand. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dale Johannesen Sent: Wednesday, September 05, 2007 2:39 PM To: LLVM Developers Mailing

Hi, I noticed that ConstantFP::get automatically returns the appropriately types Constant depending on the LLVM type passed in (i.e. if called with a vector, it returns a splat vector with the given constant). Is there any simple way to do the inverse of this function? i.e., given a llvm::Value, check whether it is either a scalar of the given constant value or a splat vector with the given

Hi All, At some point in the next week or two I'm going to remove the ConstantFP::get(type, APFloat) method. Right now, you can immediately fix your code by dropping the first 'type' argument. For example, if you have: ConstantFP::get(Ty, APFloat(1.0)) just change it to: ConstantFP::get(APFloat(1.0)) Both forms work with SVN head right now so you can migrate as

Hi, All, I want to lower 64 Bits constant such as 'long' and 'double'. So I define them like this: def CONSTI64 : InstFOO<(outs GRWideRegs:$dst), (ins i64imm:$src), "const-long $dst, $src", [(set (i64 GRWideRegs:$dst), imm:$src)]>{ let isMoveImm = 1; } def CONSTF64 : InstFOO<(outs

This code lives in DAGCombiner.cpp: ------------- // Turn 'store float 1.0, Ptr' -> 'store int 0x12345678, Ptr' if (ConstantFPSDNode *CFP = dyn_cast<ConstantFPSDNode>(Value)) { // NOTE: If the original store is volatile, this transform must not increase // the number of stores. For example, on x86-32 an f64 can be stored in one // processor operation but

On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong < yunzhong_gao at playstation.sony.com> wrote: > According to > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html, > "The high-order double-precision value (the one that comes first in > storage) must have the larger magnitude." > > So the order of the two doubles in your fp128 is not affected by the

SelectionDAG's computeKnownBits has no case for ConstantFP, e.g. Known.ones = cast <ConstantFPSDNode>(Op)->getValueAFP ().bitcastToAPInt (); I can't easily override this in target specific code. Can anyone see an issue with submitting the patch to upstream? Suggestions for an in tree target that could trigger this would be very welcome. Cheers -------------- next part

Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) ... case ISD::SINT_TO_FP: case ISD::UINT_TO_FP: case ISD::EXTRACT_VECTOR_ELT: Action = TLI.getOperationAction(Node->getOpcode(), Node->getOperand(0).getValueType());

Hi Stephen, On 22/07/13 19:19, Stephen Lin wrote: > Hi, > > I noticed that ConstantFP::get automatically returns the appropriately > types Constant depending on the LLVM type passed in (i.e. if called > with a vector, it returns a splat vector with the given constant). > > Is there any simple way to do the inverse of this function? i.e., > given a llvm::Value, check

On Mar 19, 2010, at 12:23 PM, Villmow, Micah wrote: > Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? I don't see any. > > In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) > > ... > case ISD::SINT_TO_FP: > case ISD::UINT_TO_FP: > case ISD::EXTRACT_VECTOR_ELT: > Action =

Can someone explain why TableGen can't figure this out? VCVTDQ2PS128rm: (set:isVoid VR128:v4f32:$dst, (sint_to_fp:v4f32 (bitconvert:isInt (ld:v4i32 addr:iPTR:$src)<<P:Predicate_memop>>))) llvm/tblgen: In VCVTDQ2PS128rm: Could not infer all types in pattern! The pattern as written looks like this: [(set VR128:$dst, (v4f32 (sint_to_fp (bc_memopv4i32 addr:$src))))] I'm