search for: dekruijf

...ns we're looking at a store, what this does > is making the store *p depend on the load *p. This is correct -- you > can't move store before load, otherwise load will start returning a > different value. > > Eugene > > On Fri, Jul 16, 2010 at 5:43 PM, Marc de Kruijf <dekruijf at cs.wisc.edu> > wrote: > > Hello, > > > > I'm taking a really good look at the MemoryDependenceAnalysis pass, but > I'm > > slightly confused about one little thing. I think it's a bug but I'm not > > confident enough to submit a bug report....

...lobber for MayAlias and Def for MustAlias? With the current logic DSE has to check that SI->getPointerOperand() == DepLoad->getPointerOperand(), though this is not strictly necessary -- they can be different values but be MustAlias. Eugene On Sun, Jul 18, 2010 at 2:50 AM, Marc de Kruijf <dekruijf at cs.wisc.edu> wrote: > Yes, I'm not arguing that there is a dependence, just that it's not a > clobber dependence.  The case of a load is already considered earlier in > that function and with isLoad == false it returns MemDepResult::getDef(). >  My question is:  why should...

My apologies. This problem was indeed with my changes to the backend. Next time I will more carefully examine the source of the problem. :) On Fri, Feb 26, 2010 at 12:40 PM, Marc de Kruijf <dekruijf at wisc.edu> wrote: > I've been playing around with the new IndirectBr and BlockAddress types. > I'm finding that in CodeGen, during "EliminateMostlyEmptyBlocks", > BlockAddresses are not updated to point to the newly merged block if the > original block was elimin...

I've been playing around with the new IndirectBr and BlockAddress types. I'm finding that in CodeGen, during "EliminateMostlyEmptyBlocks", BlockAddresses are not updated to point to the newly merged block if the original block was eliminated. This is causing me problems. Mind you, I'm experimenting with this using the Sparc backend, which could be the source of blame, but

On Fri, May 2, 2008 at 1:22 PM, Marc de Kruijf <dekruijf at cs.wisc.edu> wrote: > The LLVA and LLVM papers motivate the GetElementPtr instruction by arguing > that it abstracts implementation details, in particular pointer size, from > the compiler. While it does this fine for pointer addresses, it does not > manage it for address offsets...

The LLVA and LLVM papers motivate the GetElementPtr instruction by arguing that it abstracts implementation details, in particular pointer size, from the compiler. While it does this fine for pointer addresses, it does not manage it for address offsets. Consider the following code: $ cat test.c int main() { int *x[2]; int **y = &x[1]; return (y - x); } $ llvm-gcc -O3 -c test.c

On Thu, Jul 31, 2008 at 2:19 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > > really weird stuff -- unwinds are ending up in seemingly arbitrary > places... > > definitely not inside the caller's unwind block My target is x86. > > codegen doesn't know how to

Since isLoad == false means we're looking at a store, what this does is making the store *p depend on the load *p. This is correct -- you can't move store before load, otherwise load will start returning a different value. Eugene On Fri, Jul 16, 2010 at 5:43 PM, Marc de Kruijf <dekruijf at cs.wisc.edu> wrote: > Hello, > > I'm taking a really good look at the MemoryDependenceAnalysis pass, but I'm > slightly confused about one little thing.  I think it's a bug but I'm not > confident enough to submit a bug report. > > Is there a reason why re...

Hello, I'm taking a really good look at the MemoryDependenceAnalysis pass, but I'm slightly confused about one little thing. I think it's a bug but I'm not confident enough to submit a bug report. Is there a reason why read-only calls are considered to "clobber" pointers in the non-load case (which is what gets returned due to the fall-through in the switch -- see

I'm getting a very stubborn assertion failure that I don't understand. After I insert a call to an externally defined function into an invoked function, llc spits out the following assertion failure when I compile the bytecode: llc: SelectionDAGISel.cpp:4912: virtual bool llvm::SelectionDAGISel::runOnFunction(llvm::Function&): Assertion `FuncInfo.CatchInfoFound.size() ==

It sounds like Transforms/Utils/SSAUpdater may be what you are looking for. A good example of how to use it -- one that sounds very similar to what you're doing -- can be found in Transforms/Scalar/LoopRotation.cpp On Wed, Mar 7, 2012 at 2:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I am splitting a one BB loop into two BB. > > Basically, the one loop BB has 3 incoming

If I have an '&' operator inside an 'if' statement, LLVM seems to always promote a 16 bit integer type to a 32 bit integer type. I don't want this to happen because my back-end only supports 16 bit types. Why is this happening? Where might this be happening, so I can fix it? It doesn't seem to happen with the '|' operator, only '&'. Thanks!

> For example, this: > > %t0 = insertvalue { i32, i32 } undef, i32 %a, 0 > %t1 = insertvalue { i32, i32 } %t0, i32 %b, 1 > > creates the value with %a and %b as member values. Is there anyway to do it using the C++ API? It seems I need an instance of the aggregate type to pass into InsertValueInst::Create(). What is the API equivalent of "undef"? Marc On Wed,

Hello, The basic infrastructure is in place. You can create first-class structs/arrays using sequences of insertvalue. For example, this: %t0 = insertvalue { i32, i32 } undef, i32 %a, 0 %t1 = insertvalue { i32, i32 } %t0, i32 %b, 1 creates the value with %a and %b as member values. Other ways to produce aggregate values are loads, function arguments, function return values, and literal

Hi, I have a question on why gcc and llvm-gcc compile the following simple code snippet differently: extern int a; extern int *b; void foo() { int i; for (i = 1; i < 100; ++i) a += b[i]; } gcc compiles this function hoisting the load of the global variable "b" outside of the loop, while llvm-gcc keeps it inside the loop. This results in slower code on the part of

I am splitting a one BB loop into two BB. Basically, the one loop BB has 3 incoming values, one form back edge two from other edges. I want to extract the PHIs from the other two edges out into it's own BB and delete that from the loop, then redirect the backedge to the loopbody (non extracted portion) and create a new PHI coming from the extracted BB and the backedge. I can do this;

Is it necessary to modify the front-end (in this case, for C) to generate new intrinsic calls for a particular target? For instance, say I wanted to allow programmers to call a function "foo" that does some target-specific magic. I want "foo" to be handled as an intrinsic by the back-end, but all intrinsics needs the "llvm." prefix, and I can't declare a

Hello, I am implementing a code transformation that would heavily benefit from the CodeGen/StrongPHIElimination pass, but on the two bytecode files I've tested it on so far llc segfaults on both. I see there have been no substantive changes to this code since the middle of last year. Could someone please tell me what the status of this pass is? Thank you. Marc -------------- next part

My research involves subtle changes to register and stack slot allocation in the LLVM back-end. Working with the old LinearScan + VirtRegMap system was difficult, to say the least. In fact, after having now ported my stuff to work with the new "greedy" register allocator, I will even go so far to say that it was a nightmare. The new register allocator is smooth, modular, and

As part of PhD research I integrated support for code generation of idempotent (re-executable) code regions into LLVM, along with a supporting IR-level analysis to identify and demarcate large "semantically" idempotent regions [1]. Some have expressed interest the code, so here is a link that contains some documentation and pointers to the source hosted on GitHub: