search for: visitcallsit

...IntrinsicInst *In = dyn_cast<IntrinsicInst>(*I)) { > + if (In->getIntrinsicID() == Intrinsic::init_trampoline) > + return In; > + } There was no point in having the curly brackets { }. > + } > + > + return NULL; -> return 0; > +} > + > // visitCallSite - Improvements for call and invoke instructions. > // > Instruction *InstCombiner::visitCallSite(CallSite CS) { > @@ -880,10 +916,8 @@ Instruction *InstCombiner::visitCallSite(CallSite CS) { > return EraseInstFromFunction(*CS.getInstruction()); > } > > - if (BitCast...

Hi! 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! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.patch Type: text/x-diff Size: 8808 bytes Desc:

...ct.LargeS_struct* %ls, i32 0, i32 3 store i32 23, i32* %j, align 4, !tbaa !0 call void (i8*, ...)* @test(i8* getelementptr inbounds ([4 x i8]* @.str, i32 0, i32 0), i64* byval %dw, %struct.LargeS_struct* byval %ls) nounwind ret i32 0 } This transformation seems to take place in InstCombiner::visitCallSite in InstCombineCalls.cpp, which calls function isSafeToEliminateVarargsCast to decide whether it is safe to eliminate a cast instruction and replace the argument that is passed. Would it be possible to add code in isSafeToEliminateVarargsCast that checks alignments of SrcTy and DstTy and returns fa...

Hi, I would like to get a copy of all arguments of a called function in LLVM. Unfortunately, when the argument is void* the size of the pointed object in LLVM is one byte (it is treated as char*), and I cannot get the size of the pointed object in Interpreter::visitCallSite(CallSite CS). Do you know how to get this? I just would like to get a copy of the pointed object by the argument. --Nayden -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100827/3fa17364/attachment.html>

...GenericValue> > const&) (in /usr/local/bin/lli) ==9222==    by 0x85B49A: llvm::Interpreter::callFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&) (in /usr/local/bin/lli) ==9222==    by 0x85B952: llvm::Interpreter::visitCallSite(llvm::CallSite) (in /usr/local/bin/lli) ==9222==    by 0x85D638: ??? (in /usr/local/bin/lli) ==9222==    by 0x85BED8: llvm::Interpreter::run() (in /usr/local/bin/lli) ==9222==    by 0x85045A: llvm::Interpreter::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator&lt...

...ing it as the second or third argument, rather than the first! Finally I think the alloca case should come before the "hunt back in the basic block" logic, because it is the most common. > + > + // Could not find the init.trampoline call. > + return 0; > +} > + > // visitCallSite - Improvements for call and invoke instructions. > // > Instruction *InstCombiner::visitCallSite(CallSite CS) { > --- a/lib/VMCore/AutoUpgrade.cpp > +++ b/lib/VMCore/AutoUpgrade.cpp > @@ -43,6 +43,32 @@ static bool UpgradeIntrinsicFunction1(Function *F, Function *&NewFn) { &...

...m::GenericValue> > const&) (in /usr/local/bin/lli) ==9222== by 0x85B49A: llvm::Interpreter::callFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator&lt;llvm::GenericValue> > const&) (in /usr/local/bin/lli) ==9222== by 0x85B952: llvm::Interpreter::visitCallSite(llvm::CallSite) (in /usr/local/bin/lli) ==9222== by 0x85D638: ??? (in /usr/local/bin/lli) ==9222== by 0x85BED8: llvm::Interpreter::run() (in /usr/local/bin/lli) ==9222== by 0x85045A: llvm::Interpreter::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator&lt;l...

Hi! Attached patches split init.trampoline into adjust.trampoline and init.trampoline, like in gcc. As mentioned in the previous mail, I've not made a documentation patch, since I'm not sure about what the documented semantics of llvm.adjust.trampoline should be. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was

...hat could be better specified, but this is good enough to discuss. Feedback is most welcome. Abstract ======== This proposal is an attack plan for PR11895 [1]. Currently within LLVM we have two passes that are used to fold library calls: (1) `SimplifyLibCalls` and (2) `InstCombiner` (by way of `visitCallSite`). Having multiple methods to implement an optimization class makes understanding the optimizer more difficult, presents a maintenance burden, and makes it unclear where new optimizations within the class should go. As such, the two call folding methods should be combined. Each of the current met...

Yep, it sounds like a good solution, and it works for me - thanks! -mike On Mon, 10 Jan 2005 20:40:34 -0800, Reid Spencer <reid at x10sys.com> wrote: > Michael, > > I've implemented a LOADABLE_MODULE feature in the makefiles: > > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html > > The approach taken is almost what you described

Michael, I've implemented a LOADABLE_MODULE feature in the makefiles: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html The approach taken is almost what you described below. However, I want to retain the distinction between a "regular" shared library and one that can be dlopened. So, if you specify SHARED_LIBRARY=1 you get a regular shared library