similar to: [LLVMdev] replace hardcoded function names by intrinsics

On Fri, 02 Mar 2012 13:55:18 +0100 Jochen Wilhelmy <jochen.wilhelmy at googlemail.com> wrote: > Hi! > > in the llvm code there are several places with hardcoded function > names for e.g. sin, sinf, sqrt, sqrtf etc., namely > ConstantFolding.cpp > InlineCost.cpp > SelectionDAGBuilder.cpp > IntrinsicLowering.cpp > TargetLowering.cpp > > my question is:

Hi, >> in the llvm code there are several places with hardcoded function >> names for e.g. sin, sinf, sqrt, sqrtf etc., namely >> ConstantFolding.cpp >> InlineCost.cpp >> SelectionDAGBuilder.cpp >> IntrinsicLowering.cpp >> TargetLowering.cpp >> >> my question is: wouldn't it be beneficial to use intrinsics for this? >> for example a

On Fri, 02 Mar 2012 16:05:17 +0100 Duncan Sands <baldrick at free.fr> wrote: > Hi, > > >> in the llvm code there are several places with hardcoded function > >> names for e.g. sin, sinf, sqrt, sqrtf etc., namely > >> ConstantFolding.cpp > >> InlineCost.cpp > >> SelectionDAGBuilder.cpp > >> IntrinsicLowering.cpp > >>

Hi! > sin/cos etc should already be handled by lib/Analysis/ConstantFolding.cpp. > Thanks for the hint and it works! Now I have a new Problem: I have this function: float foo(float a, float b) { float x = a * b * 0.0f; return cos(0.5) * sin(0.5) * x; }; after compiling it with clang (cpp mode) and renaming _ZSt3sinf to sin and _ZSt3cosf to cos I get the following: define

Hi! I'd like to replace all calls to standard math functions (e.g. sin(0.5)) by their result. What strategy do you recommend? Should I write a pass that does only this or should I copy and modify the SCCP pass? A problem with an extra pass could be that that I need to alternate my pass and SCCP several times since the results of the math functions could be folded again. -Jochen

Dan, and anyone else interested. I am not sure if this has been discussed before, but I do have a case when the following logic fails to work: lib/Analysis/ConstantFolding.cpp static Constant *ConstantFoldBinaryFP(double (*NativeFP)(double, double), double V, double W, Type *Ty) { sys::llvm_fenv_clearexcept(); V = NativeFP(V, W); if

On Mar 1, 2010, at 9:44 AM, Jochen Wilhelmy wrote: > Hi! > > I'd like to replace all calls to standard math functions (e.g. sin(0.5)) by > their result. > What strategy do you recommend? > Should I write a pass that does only this or should I copy and > modify the SCCP pass? > > A problem with an extra pass could be that that I need to alternate > my pass and

Hi Sergei, The degree to which LLVM actually makes any guarantees about IEEE arithmetic precision is ambiguous. LangRef, for one, doesn't even mention it (it mentions formats, but nothing else). The de-facto way of interpreting holes in LangRef is to consider how the IR is used by clang and follow the path up into the C and/or C++ standards and then work from there. C describes a binding to

Dear all, I'm using IntrinsicLowering class to remove all intrinsics in LLVM byte-code. Unfortunately, I meet several problems: 1. Why I can not get the type of CallInst *CI? !CI->getType()->isVoidTy() is not working and how to solve it? This type information has some impacts with intrinsics such as flt_rounds. 2. Why Intrinsic::vastart and Intrinsic::powi are excluded from

On Sat, 2007-03-31 at 12:38 -0800, Chris Lattner wrote: > >> 3. Can I introduce an intrinsic that is actually a call to my function > >> that implements the logic? I suppose it is possible but unfortunately > >> I couldn't figure it out. For example, in GCC we can write an > >> intrinsic that translates to a C code. > > > > As part of PR1297

>> 3. Can I introduce an intrinsic that is actually a call to my function >> that implements the logic? I suppose it is possible but unfortunately >> I couldn't figure it out. For example, in GCC we can write an >> intrinsic that translates to a C code. > > As part of PR1297 (http://llvm.org/PR1297) I am about to make this > happen. There are certain kinds of

Hi, This is more of an RFC than for committing (hence the post to llvmdev) but I'd like to have some opinions on these improvements to IntrinsicLowering before I go ahead and implement the rest of the intrinsics. My main motivation for the single-thread lowering is to be able to run code that uses these intrinsics in the KLEE symbolic execution engine but I imagine it could have other uses

On 20/01/13 19:20, Caldarale, Charles R wrote: [...] > That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2 Ah. Yes, that would explain it... does this mean that I can rely on all the intrinsics listed existing for the common types (int, float, double)? Or should I be trying to follow the libc call route? I've noticed that llc is successfully

Hi! Of course nobody wants to implement unicode support for windows because windows should support an utf8-locale and windows is obsolete anyway ;-) But there is a simple solution: use boost::filesystem::path everywhere you use file names and paths, for example in clang::FileManager::getFile. With version 3 opening a file is easy: std::fstream file(path.c_str()). Internally

Hi all, It's been a long time, and I'm probably going to kill myself, but I want to try it anyway. Bug 10368 [1] tells me that ConstantExpr shouldn't automatically fold, and that this is source of many problems (most notably with traps) and code duplication. However, I'm a bit lost... There seem to be constant folding in many places like ConstantExpr::get*() uses

Hi Jochen, I just wanted to point out that if x = inf the result of x * 0 is in indeterminate form so reducing it to zero would give the wrong result in that case. Thanks, Javier On 3/3/2010 8:56 AM, Jochen Wilhelmy wrote: > Hi! > > > >> sin/cos etc should already be handled by lib/Analysis/ConstantFolding.cpp. >> >> > Thanks for the hint and it

I am using llvm-2.6 and the ConstProp.cpp file is http://llvm.org/docs/doxygen/html/ConstantProp_8cpp_source.html and the exact error message is: llvm[0]: Compiling ConstantProp.cpp for Release build (PIC) /home/tarun/Desktop/compiler/LLVM/llvm-2.6/include/llvm/Analysis/ConstantFolding.h: In member function ‘virtual bool<unnamed>::ConstantPropagation::runOnFunction(llvm::Function&)’:

Am 29.12.2011 19:52, schrieb Reid Kleckner: > I think Chris is saying that the and is necessary because with your i1 > trunc you're ignoring all of the high bits. The and implements that. > If you don't want this behavior, don't generate the trunc in the > first place and just compare the full width to zero. But if a backend sees trunc from i8 to i1 it should know

On 25.11.2010 23:56, Michael Spencer wrote: > On Nov 25, 2010, at 5:01 PM, Jochen Wilhelmy <j.wilhelmy at arcor.de > <mailto:j.wilhelmy at arcor.de>> wrote: > >> Hi! >> >> Of course nobody wants to implement unicode support for windows >> because windows should support an utf8-locale and windows is obsolete >> anyway ;-) >> >> But

Hi Hao Shen, > 1. Why I can not get the type of CallInst *CI? > !CI->getType()->isVoidTy() is not working and how to solve it? what does "not working" mean? It should work. > 2. Why Intrinsic::vastart and Intrinsic::powi are excluded from > IntrinsicLowering function? > There are no way to lower them at the byte-code level? For vastart, it probably isn't