similar to: [LLVMdev] Bug in InsertElement constant propagation?

Does anybody else have an opinion on this issue? I'm planning to submit a patch which would add a new get method for ConstantDataVector taking an ArrayRef<Constant*> and use that in the few places in constant propagation where convertToFloat is used. Let me know if you think there is a more obvious way to do it. Right now the only way to create a ConstantDataVector are those method:

Ha here is what I was missing. Thanks Jon. It still seems to me that the transformation of LLVM IR is invalid is that right? I assume we shouldn't be converting APFloat to float in order to avoid such problems? -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 9:39 AM To: Raoux, Thomas F; LLVM Developers Mailing List

I don't see a way to create a ConstantDataVector from Constant or form APFloat though. Did I oversee that? Is the solution to had a new get function in ConstantDataVector to allow that? Any hint on what would be the right fix otherwise? Thomas -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 10:30 AM To: Raoux, Thomas

I've got comments on the code change. The test cases look ok, but I haven't fully checked the math on the half-values. I checked with reference to trunk top-of-tree at revision 156617. I have not compiled the code. lib/AsmParser/LLLexer.cpp Adds support to parse format: 0xH<hexdigits> Tha 0xH format should be described in LangRef.html alongside 0xK<hex> and

Hi David, Many thanks for the comments! > Tha 0xH format should be described in LangRef.html alongside > 0xK<hex> and 0xM<hex> Done. > Declaration of "int shiftcount" should be moved to smallest nesting > possible, right after "if ( const ConstantFP ..." at line 710 > > (The code makes a lot more sense with a good comment on the

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

looks good here. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Anton Lokhmotov > Sent: Thursday, May 17, 2012 4:51 AM > To: 'David Neto' > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [PATCH] OpenCL half support > > Hi David, > > Many thanks for the comments! > >

I'm running into some pretty bad performance in llc.exe when compiling some large neural networks into code that contains some very large llvm::ConstantDataArrays, some are { size=102,760,448 }. There's a small about of actual code for processing the network, but the assembly is mostly global data. I'm finding that llc.exe memory spikes up around 30 gigabytes and the job takes 20-30

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, I have a very simple test case (thanks to bugpoint) that hit an assert in reassociate. (the assert is (C->getType()->isIntOrIntVectorTy() && "Cannot NEG a nonintegral value!"), function getNeg) The function is taking a Constant as argument, but the assert does not expect an undef. I’m not sure whose responsibility is it to handle that (caller?). Do we have to

Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------

----- 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

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());

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

Hi, It looks like SimplifyLibCalls has a tendency to emit calls to libm functions without checking with TLI whether these calls are available. For example, PowOpt has this code: struct PowOpt : public UnsafeFPLibCallOptimization { PowOpt(bool UnsafeFPShrink) : UnsafeFPLibCallOptimization(UnsafeFPShrink) {} virtual Value *callOptimizer(Function *Callee, CallInst *CI, IRBuilder<> &B)

On Tue, Aug 13, 2013 at 5:58 AM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > Hi,**** > > ** ** > > It looks like SimplifyLibCalls has a tendency to emit calls to libm > functions without checking with TLI whether these calls are available.**** > > For example, PowOpt has this code:**** > > ** ** > > struct PowOpt : public

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

On Sat, Sep 9, 2017 at 10:18 PM, Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Sep 7, 2017, at 11:06 PM, Chris Lovett via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > I'm running into some pretty bad performance in llc.exe when compiling > some large neural networks into code that contains some very large llvm::ConstantDataArrays,

Thanks for the updates! Minor comments: + if (!Accuracy) + // If it's not a floating point number then it must be 'fast'. + return HUGE_VALF; Can we add an assert instead of a comment? It's just as documenting and will catch any goofs. + // If it's not a floating point number then it must be 'fast'. + return !isa<ConstantFP>(MD->getOperand(0));

Here's a revised patch, plus patches showing how fpmath metadata could be turned on in clang and dragonegg (it seemed safest for the moment to condition on -ffast-math rather than on one of the flags implied by -ffast-math). Major changes: - The FPMathOperator class can no longer be used to change math settings, only to read them. Currently it can be queried for accuracy info. I split the