similar to: [LLVMdev] [RFC/PATCH] IntrinsicLowering improvements

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

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 10 Sep 2015, at 10:09, serge guelton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 10, 2015 at 04:20:01PM +0800, Dipanjan Das via llvm-dev wrote: >> 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

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

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

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 Zyulkyarov Barcelona Supercomputing Center

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 and or's, for example.

Hello, As an experiment, I'm simply trying to add a trivial intrinsic to LLVM, but I'm having trouble, which suggests that I'm overlooking the obvious ;) Platform is GCC-4.2.4/LLVM from SVN/x86. First, I've read the page here about 10 times, so I'll speculate that my reading comprehension is lacking: http://www.llvm.org/docs/ExtendingLLVM.html Code I've added to the

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

Sent from my iPad On Jul 17, 2013, at 8:53 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 17, 2013, at 2:12 AM, Chandler Carruth <chandlerc at google.com> wrote: > >> On Tue, Jul 16, 2013 at 9:34 PM, Bob Wilson <bob.wilson at apple.com> wrote: >>> >>> On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com>

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:

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:

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

On Jul 17, 2013, at 2:12 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, Jul 16, 2013 at 9:34 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote: >>> ** Advices

Hi, Thanks all for the insight comments. Let me sum up at a high level what proposals we actually have (sorry if I misinterpreted or missed something, do not hesitate to correct me): 1. Make LLVM defines some APIs that exposes some internal information so that a front-end can use them to build-up some diagnostics. 2. Make LLVM builds up a diagnostic and let a front-end maps this diagnostic to

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.