similar to: [LLVMdev] Question about the new version of LLVM GCC

Hi! I'm currently working on developing a new technique for alias analysis and wish to know how to compare it's results to the results that LLVM gets. The algorithm I have operates on LLVM assembly (I wrote the analysis in Haskell, so unfortunately I can't embed it into LLVM very easily). I tried using the option to print alias sets, but I'm not quite sure how to interpret the

On Mon, 25 Jun 2007, Ben Chambers wrote: > I guess what confuses me is that it doesn't seem like it was able to > figure out that *b = a. Am I looking at this wrong? Is there a more > accurate way of getting the alias information out of the pass? The answer is to not look at the alias sets. I'd suggest looking at the raw results of alias queries. To do this, use the -aa-eval

Thanks, that's a lot more like the output I was expecting. But, I'm now wondering if I'm doing something wrong because the output confuses me. When run on the program: int main() { int a = 5; int* b = &a; int* c = &a; return *b; } I would expect to see either b may alias c or b must alias c. But, it doesn't even appear in the list. Furthermore, I would expect

I realized that WinEH preparation can probably be a lot less invasive than it is currently. Initially, when I was thinking about recovering the address of an object in a parent stack frame, I thought about it in terms of "let's allocate something at a fixed offset from ebp to keep things simple". That line of thinking suggested that we needed this thing to be fundamentally different

On Wed, Mar 4, 2015 at 12:36 AM, John McCall <rjmccall at apple.com> wrote: > > On Mar 3, 2015, at 2:25 PM, Reid Kleckner <rnk at google.com> wrote: > > > > I realized that WinEH preparation can probably be a lot less invasive > than it is currently. > > > > Initially, when I was thinking about recovering the address of an object > in a parent stack

Hi, I've been stuck with this problem for a while now, and my supervisor's starting to think it's a bug in lli, but I thought I'd ask here before going down that route. I have this code, which stores an array in my 'MainClass', and prints out an element of it. Note that the print statement is irrelevant here, it segfaults regardless, and this code has been run with -O2

Hi Dan, > Changing PromoteCastOfAllocation to not replace aggregate allocas with > non-aggregate allocas if they have GEP users sounds reasonable to me. This sounds reasonable indeed, but still a bit arbitrary. Haven't figured out anything better yet, though. > Finding the maximum alignment is sometimes still useful though, so > it would be nice to update the alignment field of

Hi all, I've been looking at some LLVM assembly produced by llvm-gcc lately and I've noticed a recurring statement of which I'm not sure its purpose. For example, the following C program: int main(void) { void (*f)(void) = (0x21332); f(); } When compiled with "llvm-gcc -emit-llvm -S" will produce the following code (irrelevant parts removed): define i32 @main()

Hi Duncan, Duncan Sands wrote: > > Hi Fraser, it looks to me like you are smashing the stack. > >> define void @main() nounwind { >> allocas: >> %0 = alloca { i32, [0 x i32] }, align 8 > > ^ this allocates 4 bytes on the stack. > >> %2 = getelementptr inbounds { i32, [0 x i32] }* %0, i64 0, i32 1 > > ^ this gets a pointer to the byte

I have a compiler which generates a lot of malloc instructions for basically all data. I was rather hoping that these mallocs would be converted to allocas if the pointers didn't escape. This would require an escape analysis, and I'm not sure if LLVM has such a thing. For instance, consider this code (typical of the output of my compiler): define i32 @dontescape(i32 %x) { entry:   %t =

On 08/26/2015 07:02 PM, Chandler Carruth wrote: > On Wed, Aug 26, 2015 at 6:46 PM Swaroop Sridhar via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Currently, the alloca instruction always allocates in the generic > address space (0). > > This proposal is to extend the semantics of alloca instruction to >

Hello, I have come across an unusual behavior where instruction domination rule is violated "Instruction does not dominate all its uses." It concerns with StackColoring pass present at llvm/lib/CodeGen/StackColoring.cpp. I am reaching out to the LLVM community to help me understand the cause of this issue and the working of the pass. The IR produced at the end of the pass seems to be

On 02/28/2015 10:04 AM, Björn Steinbrink wrote: > Hi, > > On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >> ----- Original Message ----- >>> From: "Philip Reames" <listmail at philipreames.com> >>>> 6. Use the lifetime.start/lifetime.end and >>>> invariant.start/invariant.end intrinsics where possible >>> Do you find these

Hi all, I'm currently running into some problems with instcombine changing the type of alloca instructions. In particular, the PromoteCastOfAllocation looks at any allocation instruction that is used by a bitast. It does a few checks, but basically tries to change the type of the alloca instruction to the type pointed to by the bitcasted type. The current heuristic for determining if this is

I'm working on the code to handle GC tracing of "intermediate values" (as described in the GC doc), and I've run into a weird problem. (Note, this has nothing to do with the patch I have proposed, this error occurs with regular old pointer-allocas.) The exception I am getting occurs in this code here in SelectionDAGBuilder.cpp: *case* *Intrinsic*::gcroot: *if* (GFI) {

> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > >> On 2015.02.28 14:23:02 -0800, Philip Reames wrote: >>> On 02/28/2015 10:04 AM, Björn Steinbrink wrote: >>> Hi, >>> >>>> On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >>>> ----- Original Message ----- >>>>> From: "Philip

On Fri, Jan 15, 2010 at 11:02 AM, Dan Gohman <gohman at apple.com> wrote: > > On Jan 13, 2010, at 12:11 PM, Talin wrote: > > > > It depends on whether or not unions can be passed around as SSA values or > not. I can think of situations where you would want to. > > I'm skeptical that you *really* want to (i.e. that you wouldn't > be better off just

Hi Fraser, it looks to me like you are smashing the stack. > define void @main() nounwind { > allocas: > %0 = alloca { i32, [0 x i32] }, align 8 ^ this allocates 4 bytes on the stack. > %2 = getelementptr inbounds { i32, [0 x i32] }* %0, i64 0, i32 1 ^ this gets a pointer to the byte after the 4 allocated bytes. > %3 = bitcast [0 x i32]* %2 to i8* > call void

On 2015.02.28 14:23:02 -0800, Philip Reames wrote: > On 02/28/2015 10:04 AM, Björn Steinbrink wrote: > >Hi, > > > >On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: > >>----- Original Message ----- > >>>From: "Philip Reames" <listmail at philipreames.com> > >>>>6. Use the lifetime.start/lifetime.end and >

Hello Duncan and Jon, I am the criminal responsible for the tail call implementation in the backends. On Mon, Feb 23, 2009 at 9:17 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jon, > >> >From what I have understood of the LLVM docs about when tail calls get >> eliminated on x86 and x64 it should be a tail call, yes. See below. > this list is for the code