similar to: [LLVMdev] Lowering intrinsics in Codegen.

Hi Sanjoy, > Attached set of patches splits llvm.init.trampoline into an "init" > phase and an "adjust" phase, as discussed on the "Go on dragonegg" > thread. thanks for doing this. The patches look good, though the decomposition into individual patches is not that great (since things won't always work, in fact not even compile I think, with not all

Dear LLVM-Mailing list, I have a beginners question again - please don't be mad at me! I was playing around with llvm::Module instance and ended in iterating over all global values and functions. I then noticed the function "llvm.memcpy". As I understood, this is an intrinsic coming from the LLVM. So far so good! I then emitted an object file with the llvm::ExecutionEngine and

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

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

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

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

I am iterating through Modules symbols for 'test/CodeGen/X86/memcpy.bc I get :- ---------- Functions ---------- llvm.memcpy.i64 Mangled name = llvm.memcpy.i64 DefaultVisibility ExternalLinkage - Externally visible. my_memcpy Mangled name = my_memcpy DefaultVisibility ExternalLinkage - Externally visible. my_memcpy2 Mangled name =

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

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 Sat, Jul 18, 2009 at 2:21 PM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > I am working on the COFF backend and am wondering where llvm.memcpy gets > lowered to memcpy ? It's done by ISel. See SelectionDAG::getMemcpy. -Eli

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.

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 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, > 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 Jul 18, 2009, at 2:56 PM, Aaron Gray wrote: > I am iterating through Modules symbols for 'test/CodeGen/X86/memcpy.bc If you're iterating over functions, just ignore all intrinsics. -Chris > > I get :- > > ---------- Functions ---------- > llvm.memcpy.i64 > Mangled name = llvm.memcpy.i64 > DefaultVisibility > ExternalLinkage -

Ignore the suggested fix in my earlier post. How about this? diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp index 20c81c3..b8ebf42 100644 --- a/lib/Target/X86/X86ISelLowering.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, if (!Subtarget.is64Bit()) { // These

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

LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. The library functions defined in RuntimeLibCalls.def (among others) are these: HANDLE_LIBCALL(SRA_I16, "__ashrhi3") HANDLE_LIBCALL(SRA_I32, "__ashrsi3") HANDLE_LIBCALL(SRA_I64, "__ashrdi3") However, setting

Hello, my target has libcall support for long long shifts. I already have the following lines in my Lowering constructor: setLibcallName(RTLIB::SHL_I64, "__llshl"); setLibcallName(RTLIB::SRL_I64, "__llshru"); setLibcallName(RTLIB::SRA_I64, "__llshr"); and setOperationAction(ISD::SHL, MVT::i64, Expand); setOperationAction(ISD::SRA, MVT::i64,