Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Def_Use chain"
2011 May 07
1
[LLVMdev] def-use chain for Instruction
Hello all,
I am a LLVM newer who want to obtain the use-def chain for all instruction
of a sample code, for this purpose i use the following code.
///////////////sample code://///////////////////////
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#define ARRAY_SIZE 5
int main() {
int x, y, holder;
int k,z,f,i;
z=0;
f=0;
k=0;
for(x = 0; x < ARRAY_SIZE;
2011 Dec 12
1
[LLVMdev] problem with runOnLoop
Thank you for your reply
Yes, I change them, so what should I do for another loops?
On Mon, Dec 12, 2011 at 7:54 PM, neda 8664 <neda8664 at gmail.com> wrote:
> Thank you for your reply
>
> Yes, I change them, so what should I do for another loops?
>
> On Mon, Dec 12, 2011 at 7:42 PM, John Criswell <criswell at illinois.edu>wrote:
>
>> On 12/12/11 9:59 AM,
2011 Dec 12
4
[LLVMdev] problem with runOnLoop
hi all,
I want access to all basic blocks of function in a loop, so I used the
following code:
*bool parallel::runOnLoop(Loop *L, LPPassManager &LPM)
{
for (Function::iterator bi= func->begin(); bi != func->end(); bi++){
//
}
}*
First loop run without problem, but for second loop I get the following
error:
*0 libLLVM-2.9.so 0x0137d530
1 libLLVM-2.9.so 0x0137fa6c
2
2011 Dec 12
0
[LLVMdev] problem with runOnLoop
On 12/12/11 10:25 AM, neda 8664 wrote:
>
> Thank you for your reply
>
> Yes, I change them, so what should I do for another loops?
I don't really know what you should do since I don't know what your code
does. All I know is that it's changing the function's control-flow graph.
If you're not modifying the structure of the loops in the function, then
you can
2011 Oct 13
6
[LLVMdev] BasicBlock succ iterator
Hi, All
I want to implement DSWP Which is used for parallelization of loops. For
this purpose, the loop was replaced with a new basic block in main function.
And new functions were created and basic blocks of Loop assigned to them.I
have checked blocks and branches for Succ and Pred relation and I have not
found any problems.
However I get the following error:
*
**opt:
2011 Dec 12
1
[LLVMdev] problem with runOnLoop
I am changing structure of loops, I used std::vector<> but i get same
error, I can’t use FunctionPass :(
On Mon, Dec 12, 2011 at 8:03 PM, John Criswell <criswell at illinois.edu>wrote:
> On 12/12/11 10:25 AM, neda 8664 wrote:
>
> Thank you for your reply
> Yes, I change them, so what should I do for another loops?
>
>
> I don't really know what you should
2011 Jan 28
2
[LLVMdev] extract thread form sequential program
I want automatically parallelize sequential program in thread level to run
on multi-core
processors with software pipelining and use llvm. is it a suitable tools in
this project ?
can you help me in this topic?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110128/b84ebf3d/attachment.html>
2011 Sep 20
2
[LLVMdev] code generation
I've study their work carefully.
My problem is the implementation of threads in llvm after partitionning. I
want to have information about how to implement producer/consumer thread in
llvm.
I do not know where I should start in llvm for code generation and create
thread and insert produce and consume statement .
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2007 Jul 12
2
[LLVMdev] BasicCallGraph patch
The current BasicCallGraph will miss call sites like this:
%tmp86 = call i8* (...)* bitcast (i8* ()* @find_ispell to i8* (...)*)( )
; <i8*> [#uses=1]
Here the direct user of @find_ispell is a ConstantExpr.
I added several lines of code to address this case.
Below is the output of command: svn diff lib/Analysis/IPA/CallGraph.cpp
Attached is LLVM asm files with such function calls.
2005 May 11
3
[LLVMdev] Computing live values
Say I want to find all LLVM Value*-es that a live on exit from a basic block.
What's the best way?
- The 'LiveRange', 'LiveVariables' and 'LiveIntervals' classes seem to be tied
to register allocation.
- The ./lib/Target/SparcV9/LiveVar/FunctionLiveVarInfo.h file seem to provide
what I need, but it's no a public header.
- Volodya
2011 Aug 07
4
[LLVMdev] profile.pl
i could not use profile.pl, however i did reinstall the llvm but didn't
solve my problem. is there is another way to extract profilling information
in llvm?
i have another question, i want know how can estimate execution time for
each operand such as mul ,add, ... ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2005 May 11
1
[LLVMdev] Computing live values
On Wed, 11 May 2005, Alkis Evlogimenos wrote:
> On Wed, 2005-05-11 at 13:17 -0500, Chris Lattner wrote:
>> On Wed, 11 May 2005, Vladimir Prus wrote:
>>> Say I want to find all LLVM Value*-es that a live on exit from a basic block.
>>> What's the best way?
>>>
>>> - The 'LiveRange', 'LiveVariables' and 'LiveIntervals' classes
2007 Jul 17
0
[LLVMdev] BasicCallGraph patch
On Thu, 12 Jul 2007, Zhongxing Xu wrote:
> The current BasicCallGraph will miss call sites like this:
> %tmp86 = call i8* (...)* bitcast (i8* ()* @find_ispell to i8* (...)*)( )
> ; <i8*> [#uses=1]
>
> Here the direct user of @find_ispell is a ConstantExpr.
> I added several lines of code to address this case.
> Below is the output of command: svn diff
2014 Sep 25
2
[LLVMdev] MachineRegisterInfo use_iterator/reg_iterator?
Hi folks,
I would like to find out the machine instructions that use some given registers in the reverse order, and I came across these iterators (use_iterator/reg_iterator). However, there are two things I noticed:
1) These iterators seem to traverse the machine function a bit differently from what I get from the machine function dump. In other words, the use_iterator list is not constructed in
2010 Jan 25
3
[LLVMdev] Deterministic iteration over llvm iterators
Forgot cc, the entire group.
How can deterministically iterate over the uses of a variable. i.e. the uses
should be any particular order that doesn't change from execution to
execution of the opt tool.
To make myself more clearer, here is a snippet of code that has Values
reordered each time I analyze a particular piece of code(which doesn't
change) with the LLVM opt tool and my LLVM
2007 Jul 17
2
[LLVMdev] BasicCallGraph patch
I am doing inter-procedural static analysis, so I need to do DFS of call
graph. llvm-gcc sometimes generates this kind of call instruction, which
cause the call graph to be incomplete.
But thanks for your information, instcombine really solves the problem.
On 7/17/07, Chris Lattner <sabre at nondot.org> wrote:
>
> On Thu, 12 Jul 2007, Zhongxing Xu wrote:
> > The current
2009 Jul 17
2
[LLVMdev] Bug in LiveIntervals? Please Examine
In LiveIntervals::processImplicitDefs() we have this:
for (MachineRegisterInfo::use_iterator UI = mri_->use_begin(Reg),
UE = mri_->use_end(); UI != UE; ) {
MachineOperand &RMO = UI.getOperand();
MachineInstr *RMI = &*UI;
++UI;
MachineBasicBlock *RMBB = RMI->getParent();
if (RMBB == MBB)
continue;
const
2008 Dec 05
1
[LLVMdev] replacing a global variable by a constant
Thanks a lot for your help Matthijs! :)
basically this does the job quite nicely I think:
for (llvm::GlobalVariable::use_iterator U = gv->use_begin(); U !=
gv->use_end(); ++U) {
llvm::Instruction *I = llvm::cast<llvm::Instruction>(U);
I->replaceAllUsesWith(constPtr);
I->eraseFromParent();
}
Cheers,
Ralf
Matthijs Kooijman wrote:
> Hi Ralf,
>
>
>> I
2009 Apr 21
4
[LLVMdev] Iterating over all uses of a Function
Hi,
I try to iterate over all uses of a Function with the following
code (simplified):
for (Value::use_iterator UI = F->use_begin(), UE = F->use_end();
UI != UE; ++UI) {
if (CallInst* I = dyn_cast<CallInst>(*UI)) {
// do something interesting
}
}
This works on Linux, but on Windows the dyn_cast fails, even
though the only use of F in that
2011 Sep 07
2
[LLVMdev] llvm-prof
hi
I changed llvm-prof and make it, but when use profile.pl ,i could not see
any change in result.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110907/fc9be189/attachment.html>