Displaying 8 results from an estimated 8 matches for "vuse".
Did you mean:
use
2011 Dec 20
2
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
Hi,
I see that there are two functions in your code that are O(n^2) in
number of instructions of the program: getCandidatePairs and
buildDepMap. I think that you could make these two functions faster
if you work on some form of factored def-use chains for memory, like
the VUSE/VDEFs of GCC.
I was trying to find a similar representation in LLVM: isn't there already
a virtual SSA representation for memory references in LLVM?
Thanks,
Sebastian
--
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
2011 Dec 20
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
...gt;
> I see that there are two functions in your code that are O(n^2) in
> number of instructions of the program: getCandidatePairs and
> buildDepMap. I think that you could make these two functions faster
> if you work on some form of factored def-use chains for memory, like
> the VUSE/VDEFs of GCC.
Thanks for the comment! I am not aware of anything along these lines,
although it would be quite helpful. The pass spends a significant amount
of time running the aliasing-analysis queries.
-Hal
>
> I was trying to find a similar representation in LLVM: isn't there alre...
2004 Jul 21
0
[LLVMdev] GC questions.
Ok, that makes sense :).
, Tobias
On Wed, 21 Jul 2004, Chris Lattner wrote:
> On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > > return *FieldPtr;
> > > }
> >
> > Hm, but doesn't FieldPtr need to be calculated target-specific in those
> > cases?
>
> For the field pointer, one
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > return *FieldPtr;
> > }
>
> Hm, but doesn't FieldPtr need to be calculated target-specific in those
> cases?
For the field pointer, one could use the getelementptr instruction:
%pairty = { sbyte, sbyte, int* }
%pairPtr = ...
%fieldptr = getelementptr
2004 Jul 22
2
[LLVMdev] GC questions.
...alues.size(); i != e; ++i) {
< Value* v = GCRootValues[i]->getOperand(1);
< AllocaInst* a = new AllocaInst(v->getType(), 0, "stackGcRoot", cast<Instruction>(v));
< GCRootValues[i]->setOperand(1, a);
<
< std::vector<Instruction*> vUses;
< std::vector<Instruction*> vLoads;
<
< for (Value::use_iterator j = v->use_begin(), e = v->use_end(); j != e; ++j) {
< if (Instruction *Inst = dyn_cast<Instruction>(*j)) {
< LoadInst* l = new LoadInst(a, "loadGcRoot", Inst...
2008 Jun 11
1
[LLVMdev] Compiling llvm libraries to run on iPhone
> On Tue, Jun 10, 2008 at 4:50 PM, Robert Grapes
> <robert_grapes at hotmail.com> wrote:
> > llvm[3]: Compiling SelectionDAGISel.cpp for Release build
> >
> > /var/folders/Xq/XqzGACxLHWq4Af0cQbEMdE+++TI/-Tmp-//cc6xGQcn.s:unknown:immediate
> > value (-288) too large
> >
> > Any help would be really appreciated,
>
> That looks like an internal
2011 Dec 14
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
Tobias,
I've attached an updated copy of the patch. I believe that I accounted
for all of your suggestions except for:
1. You said that I could make AA a member of the class and initialize it
for each basic block. I suppose that I'd need to make it a pointer, but
more generally, what is the thread-safely model that I should have in
mind for the analysis passes (will multiple threads
2011 Dec 02
5
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
On 11/23/2011 05:52 PM, Hal Finkel wrote:
> On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote:
>> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote:
>>> > > Tobias,
>>> > >
>>> > > I've attached an updated patch. It contains a few bug fixes and many
>>> > > (refactoring and coding-convention) changes inspired