similar to: [LLVMdev] Getting started with LLVM Passes

Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Getting started with LLVM Passes"

2005 Jul 12
0
[LLVMdev] Getting started with LLVM Passes
Chris, I've now figured out how to track and single out specific instructions, which was ridiculously easy. Thanks! I'm now on to trying to find more detail about those instructions, such as the values and addresses of the operands in memory (or, in the case of operands which are pointers, trying to get the pointer values, addresses, and values stored at location specified by
2009 Sep 28
4
[LLVMdev] Printing Function Arguments
ivtm wrote: > Hey Oscar, > > I want to extract information from the instruction. > > Think writing a simple interpreter. > > I already have the CallInst instance (described above in the message). > > Via ci->getOperand(1) say I can get the 'i32 8' parameter and I can get the > 'i32' and '8' separately as Nick described. > > But I
2004 Jun 23
2
[LLVMdev] weird issue with mem2reg, still
On Wed, 23 Jun 2004, Patrick Meredith wrote: > Somehow it fails with operand out of bounds when the number of operands > is 2 and I am asking for the second operand. Second meaning operand 1. Okay, so you have something like this: if (CallInst *CI = dyn_cast<CallInst>(...)) { ... = CI->getOperand(1); } Can you send in this snippet of code, the assertion, and the
2006 Mar 03
1
[LLVMdev] printing constants
Sir, I am using the op_begin and op_end iterator for iterating over the operands as mentioned below. for (User::op_iterator operand=j->op_begin(),operand_end=j->op_end();operand!=operand_end;++operand){ Value *v=operand->get(); const Type *t=v->getType(); cerr<<endl<<" operand: "<<"[ "<<v->hasName()<<"
2004 Oct 12
1
[LLVMdev] Re: Hide visible string in variable (Chris Lattner)
Hi, Thanks so much at first. > Here are some observations: > > > for C level, > > > > char a[]="global string test"; > > for(i=0;i<strlen(a);i++){ > > a[i]= a[i]^RANDMON; > > } > > If you compile this C code, "global string test" will occur in the program > binary, so you have not obfuscated anything. You can
2004 Jun 23
0
[LLVMdev] weird issue with mem2reg, still
void MetaSplit::handleProgramUses(Value *V){ if(!isa<BasicBlock>(V)) programValues.insert(V); if(User *U = dyn_cast<User>(V)){ User::op_iterator OB = U->op_begin(), OE = U->op_end(); for(; OB != OE; ++OB){ if(CallInst *CI = dyn_cast<CallInst>(*OB)){ Function *F = CI->getCalledFunction(); if(F == ii || F == fi || F == vi || F == di || F == ci
2009 Sep 28
0
[LLVMdev] Printing Function Arguments
Hi Nick, I parsed your message again carefully and did some experiments. I guess the: for (User::op_iterator i = I->op_begin(), e = I->op_end(); i != e; ++i) { } iterates over the operands of the instruction "I", which are as you said, *other* instructions. But if I want to get other information about the instruction, say the type of the operands, then I still need to figure
2015 Sep 13
3
RFC: faster simplifyInstructionsInBlock/SimplifyInstructions pass
LLVM has two similar bits of infrastructure: a simplifyInstructionsInBlock function and a SimplifyInstructions pass, both intended to be lightweight “fix up this code without doing serious optimizations” functions, as far as I can tell. I don’t think either is used in a performance-sensitive place in-tree; the former is mostly called in minor places when doing CFG twiddling, and the latter seems
2010 Jan 09
0
[LLVMdev] [PATCH] Fix nondeterministic behaviour in the CodeExtractor
On Jan 8, 2010, at 5:01 PM, Julien Lerouge wrote: > Hello, > > The CodeExtractor contains a std::set<BasicBlock*> to keep track of > the > blocks to extract. Iterators on this set are not deterministic, and so > the functions that are generated are not (the order of the > inputs/outputs can change). > > The attached patch uses a SetVector instead. Ok to apply ?
2015 May 19
2
[LLVMdev] Removing AvailableExternal values in GlobalDCE (was Re: RFC: ThinLTO Impementation Plan)
On Fri, May 15, 2015 at 11:20 PM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 15, 2015 at 2:52 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> On Fri, May 15, 2015 at 1:15 PM, Teresa Johnson <tejohnson at google.com> >> wrote: >>> >>> On Fri, May 15, 2015 at 10:04 AM, David Blaikie <dblaikie at
2010 Jan 09
2
[LLVMdev] [PATCH] Fix nondeterministic behaviour in the CodeExtractor
Hello, The CodeExtractor contains a std::set<BasicBlock*> to keep track of the blocks to extract. Iterators on this set are not deterministic, and so the functions that are generated are not (the order of the inputs/outputs can change). The attached patch uses a SetVector instead. Ok to apply ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F
2018 May 21
2
Getting variable names from LLVM Pass
Hi, I want to retrieve the variable names used in a statement, I tried the following snippet, but it only gives me the variable named in llvm bitcode. I need the variable name in source code. for (auto op = I.op_begin(); op != I.op_end(); op++) { Value* v = op->get(); StringRef name = v->getName(); } Is there specific documentation I can
2006 Mar 03
1
[LLVMdev] printing constants
Sir, Given code like: > > X = add int Y, 1 > Z = mul int X, 17 while I iterate over the operands of the first instruction i want to print the variable x ,as well as the constant 1 and while i iterate over the second instruction i want to print variable x and constant 17. what should I do? thanking you, yours sincerely, anubham suresh TU-Darmstadt --- llvmdev-request at
2015 Jun 04
2
[LLVMdev] Removing AvailableExternal values in GlobalDCE (was Re: RFC: ThinLTO Impementation Plan)
On Wed, Jun 3, 2015 at 2:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-03, at 09:56, Teresa Johnson <tejohnson at google.com> wrote: >> >> On Tue, May 19, 2015 at 1:18 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> >>> On Tue, May 19, 2015 at 1:05 PM, Teresa Johnson <tejohnson at
2009 Sep 06
3
[LLVMdev] Graphviz and LLVM-TV
On 2009-09-06 19:57, Ioannis Nousias wrote: > Edwin, > > thank you for your effort, but I'm not sure I understand. > Are you describing a graph traversal problem? Is the data model stored > in a predecessor/successor fashion, which requires you to 'walk' the > graph in order to visit all nodes? (and what happens when you have > disjointed DFGs?). Sorry for the
2015 May 19
2
[LLVMdev] Removing AvailableExternal values in GlobalDCE (was Re: RFC: ThinLTO Impementation Plan)
On Tue, May 19, 2015 at 12:41 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, May 18, 2015 at 9:09 PM, Teresa Johnson <tejohnson at google.com> > wrote: >> >> On Fri, May 15, 2015 at 11:20 PM, Teresa Johnson <tejohnson at google.com> >> wrote: >> > On Fri, May 15, 2015 at 2:52 PM, David Blaikie <dblaikie at gmail.com>
2011 Sep 22
2
[LLVMdev] How to const char* Value for function argument
Hi, I'm trying to replace function call with call to wrapper(function_name, num_args, ...), where varargs hold args of original call. Function* launch = Function::Create( TypeBuilder<int(const char*, int, ...), false>::get(context), GlobalValue::ExternalLinkage, "kernelgen_launch_", m2); { CallInst* call = dyn_cast<CallInst>(cast<Value>(I)); if
2008 Mar 12
3
[LLVMdev] Question about use-def chain
Programmers’ manual says we can iterate over a use-def chain by op_iterator. It works fine except for load and store instruction of stack variables. For example, a simple bitcode is like the below. i = alloca i32 store i32 0, i32* %i, align 4 %tmp1 = load i32* %i, align 4 If I apply a use-def chain to load instruction, I get alloca instruction. I think store instruction is a correct
2007 Sep 23
2
[LLVMdev] RFC: Tail call optimization X86
The patch is against revision 42247. -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-src.patch Type: application/octet-stream Size: 62639 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070923/4770302f/attachment.obj>
2008 Apr 29
5
[LLVMdev] [PATCH] use-diet for review
Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified