search for: gooseberri

Is this issue still active? It sounded as though Dan or Hal were looking at it but I havent seen an response. Should I resubmit as a bug so it gets tracked? thanks for your help On Tue, Jan 31, 2012 at 1:35 PM, Dan Gohman <gohman at apple.com> wrote: > On Jan 30, 2012, at 4:04 PM, Hal Finkel wrote: > > > > Dan, where in the code is this done? I see a comment at the end of

Many of our pointers point into a structure where they could be considered as having the same base address. We use tbaa to indicate which ones could or could not alias because they are pointing into different substructures. This is exactly the sort of requirement that invoked the need for the restrict modifier in g++, c++0x etc. If I understand you correctly that cannot be expressed in llvm ir

In our case basicaa alone returns "may alias" on our pointers and we want to override that with tbaa data to "Wont alias" when we know that the pointers will never alias. So its not covered by your case. Since the basicaa pass doesnt chain according to the llvm docs, it should have the last chance to affect the aliasing information, and that means it should be added first. If

On Fri, 2012-01-27 at 16:46 -0800, Dan Gohman wrote: > On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote: > > > Our application generates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have

On Sat, Dec 11, 2010 at 4:19 PM, Maurice Marks <maurice.marks at gmail.com> wrote: > In my llvm jit project I needed to lookup BB addresses at execution time and > then jump to the corresponding BB. A C++ routine called at runtime from IR > finds the right BB, gets its BlockAddress and returns it as an i8*. The IR > does an indirectbr on this value... > Well, not really. The

On Jan 30, 2012, at 4:04 PM, Hal Finkel wrote: > > Dan, where in the code is this done? I see a comment at the end of > BasicAliasAnalysis::aliasGEP regarding "protecting TBAA in the case of > dynamic indices into arrays of unions"; are you referring to that? Yes. And looking at the testcase, this appears to be the problem. Dan

In my llvm jit project I needed to lookup BB addresses at execution time and then jump to the corresponding BB. A C++ routine called at runtime from IR finds the right BB, gets its BlockAddress and returns it as an i8*. The IR does an indirectbr on this value... Well, not really. The routine returns the address of a BlockAddress node. Is there any way to get the real runtime code address for the

I wanted to update the llvm list on an offline discussion I was having with Rafael about a problem we have been seeing trying to compile an "interpreter" type of program with clang. It was producing a huge number of spills, something we had seen in llvm 2.8, and it seemed to have recurred in 3.0. Following Rafael's advice we added -disable-early-taildup to llc and the spills

On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote: > Our application generates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have lots of derived pointers and we use extensive tbaa metadata to

Our application generates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have lots of derived pointers and we use extensive tbaa metadata to indicate which pointers dont alias. Some of this seemed to be

Mi Maurice, A follow up to Andy's comments: MCJIT can find line numbers for ELF files, at least in limited circumstances. I know because I broke the regression test for it while doing some cleanup recently. ;) Looking at lib/ExecutionEngine/OProfileJIT/OProfileJITEventListener.cpp, I see the line: // TODO: support line number info (similar to IntelJITEventListener.cpp) >From a glance at