search for: intrinsiclowering

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

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 such as a whole-program LTO that lowers atomic operations...

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 possible at the byte-code level. For powi, my guess is that it is a mistake and should be lowered. Ciao, Duncan.

Hi Peter, > 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 such as a whole-program LTO > that lowers atomic operations to more efficient non-atomic operations > when it is known to be safe to do so. instead, how about writing an LLVM IR pass that

...> > As part of PR1297 (http://llvm.org/PR1297) I am about to make this > happen. There are certain kinds of intrinsics that want to have a > function body generated for them if a target or code generator cannot > handle the intrinsic natively. For example, the company I work for has IntrinsicLowering already does this. It lets you lower intrinsics to arbitrary LLVM calls, including calls to external functions. -Chris -- http://nondot.org/sabre/ http://llvm.org/

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 c/c++ frontend (clang) could translate the function calls to intrinsics and then in a very late step (IntrinsicLowering.cpp?) translate it back to function calls. an opencl frontend the...

It seems that several intrinsics are missing from this routine. In particular, floor, which was causing problems in the mips16 port. Is there some reason to not add the ones that are missing? For example, adding the following fixed my problem with floor. case Intrinsic::floor: EnsureFPIntrinsicsExist(M, I, "floorf", "floor", "floor");

Ooops... Ignore this previous mail. The problem still exists with this change. On 07/28/2013 02:36 PM, reed kotler wrote: > It seems that several intrinsics are missing from this routine. > > In particular, floor, which was causing problems in the mips16 port. > > Is there some reason to not add the ones that are missing? > > For example, adding the following fixed my

On Sun, Jul 28, 2013 at 3:02 PM, Reed Kotler <rkotler at mips.com> wrote: > Ooops... Ignore this previous mail. > > The problem still exists with this change. > > > On 07/28/2013 02:36 PM, reed kotler wrote: > >> It seems that several intrinsics are missing from this routine. >> >> In particular, floor, which was causing problems in the mips16 port.

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 c/c++ >> frontend (clang) could translate the function calls to intrinsics and >> then in a very late >> step (IntrinsicLowering.cpp?)...

...97 (http://llvm.org/PR1297) I am about to make this > > happen. There are certain kinds of intrinsics that want to have a > > function body generated for them if a target or code generator cannot > > handle the intrinsic natively. For example, the company I work for has > > IntrinsicLowering already does this. It lets you lower intrinsics to > arbitrary LLVM calls, including calls to external functions. I think that when Ferad said "in GCC we can write an intrinsic that translates to a C code" meant that the intrinsic would be expanded to have a body much as I'm pla...

...: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: wouldn't it be beneficial to use intrinsics for this? > for example a c/c++ > frontend (clang) could translate the function calls to intrinsics and > then in a very late > step (IntrinsicLowering.cpp?) translate it back to fun...

...k 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 > >> TargetLowering.cpp > >> > >> my question is: wouldn't it be beneficial to use intrinsics for > >> this? for example a c/c++ > >> frontend (clang) could translate the function calls to intrinsics > >> and then in a very late > &gt...

...nclude <float.h> static int isnan(double x) { return _isnan(x); } #else Right now I'm defining that defines flags directly when compiling the files, but I think it would be better to add them to the configure.h.in file. * struct to classes due to link errors include\llvm\CodeGen\IntrinsicLowering.h: struct IntrinsicLowering -> class IntrinsicLowering { public: include\llvm\Type.h: struct Type -> class Type { public: include/llvm/Target/TargetJITInfo.h: struct TargetJITInfo -> class TargetJITInfo { public: --- Paolo Invernizzi -------------- next part -------------- An embed...

...Args, *this, dl); return CallResult.second; I have two questions here: 1. Is it okay to allow the targets to choose the name, similar to RTLIB:: enum way for other calls. ? 2. Why a prototype for "memcpy" isn't being added? Could we have done this intrinsic lowering using the IntrinsicLowering class? - Sanjiv

...e intrinsic is equivalent to gcc built-in function __builtin_object_size. But I don't call __builtin_object_size explicitly in my source code. Maybe headers what I include call the built-in somewhere. How do I eliminate such built-in function call in LLVM bitcode, or what code should I add into IntrinsicLowering.cpp to handle this problem. Any suggestion or comment is welcomed. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130509/975e8341/attachment.html>

...oblem getting source-level debug info using Clang and LLVM 2.9 libraries. I compile the code with -g and -O3 (or even -O1) and I'm receiving the following error: LLVM ERROR: Code generator does not support intrinsic function 'llvm.dbg.value'! make: *** [all] Error 1 Which I found is in IntrinsicLowering.cpp and that's because there isn't any case for llvm.dbg.value. I want to ask if I'm missing something ? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130703/8e287787/attachment.html...

Hello, I can see the occurrences of several LLVM intrinsic functions in the LLVM IR generated by llvm-dis disassembler. Is there any means to rewrite these functions reliably using basic LLVM IR statements? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, > IntrinsicLowering already does this. It lets you lower intrinsics to > arbitrary LLVM calls, including calls to external functions. I will try to do that in IntrinscLowering class. May you point me an intrinsic implementation that lowers to an llvm call. Thanks for advices ans hints, Ferad -- Ferad Zyulkyar...

On Sat, 31 Mar 2007, Ferad Zyulkyarov wrote: >> IntrinsicLowering already does this. It lets you lower intrinsics to >> arbitrary LLVM calls, including calls to external functions. > > I will try to do that in IntrinscLowering class. May you point me an > intrinsic implementation that lowers to an llvm call. bswap expands into a series of shifts...