Displaying 8 results from an estimated 8 matches for "vusing".
Did you mean:
using
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
2011 Dec 20
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
On Tue, 2011-12-20 at 13:57 -0600, Sebastian Pop wrote:
> 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.
Thanks for the
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.
Ok, here's the new patch. (Please tell me if I shouldn't mail patches
directly on the mailing list.)
While I was editing LowerGC.cpp I made a little test (not part of this
patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new
intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer
directly instead and transforms it into an alloca. The idea is the
2008 Jun 11
1
[LLVMdev] Compiling llvm libraries to run on iPhone
...a.tigris.org/) to reduce the issue if possible, then send
> a bug-report to whoever distributes your ARM compiler. (For an iPhone,
> I'm guessing that's Apple.)
>
> -Eli
Hi Eli,I'm pretty sure that the compiler I'm using is llvm-gcc$ /usr/local/bin/arm-apple-darwin-gcc -vUsing built-in specs.Target: arm-apple-darwinConfigured with: ../../llvm-gcc-4.0-iphone/configure --enable-llvm=/Users/ur/llvm-svn --enable-languages=c,c++,objc,obj-c++ --target=arm-apple-darwin --enable-sjlj-exceptions --with-heavenly=/usr/local/share/iphone-filesystem --with-as=/usr/local/bin/arm-apple...
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