search for: taodyne

On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin <christophe at taodyne.com> wrote: > What guarantees does LLVM try to provide regarding source code compatibility? None. > Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:0...

On 3 févr. 2010, at 17:54, Eli Friedman wrote: > On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin > <christophe at taodyne.com> wrote: >> What guarantees does LLVM try to provide regarding source code compatibility? > > None. And this is a good thing because... ? Christophe

On Wed, Feb 3, 2010 at 9:34 AM, Christophe de Dinechin <christophe at taodyne.com> wrote: > >>> Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $" at the bottom, as if nothing had changed...

>> Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $" at the bottom, as if nothing had changed since then, when the code it displays is actually less than a week old... I guess the source code snippets are updated

What guarantees does LLVM try to provide regarding source code compatibility? Case in point: rev 94686 (http://llvm.org/viewvc/llvm-project?view=rev&revision=94686) breaks any code that creates a JIT. For example, we used to construct a FunctionPassManager with a ModuleProvider, it's now to be done with a Module. I cannot ship source code for my own project that is compatible with both

On Feb 3, 2010, at 12:26 PM, Christophe de Dinechin wrote: > On 3 févr. 2010, at 17:54, Eli Friedman wrote: > >> On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin >> <christophe at taodyne.com> wrote: >>> What guarantees does LLVM try to provide regarding source code compatibility? >> >> None. > > And this is a good thing because... ? It avoids having to deal with backward compatibility cruft? It's a pain for client code, but I suspect that for...

JIT::runJITOnFunctionUnlocked makes sure that functions referenced by the current function are JIT-ed. In my case, I may be compiling foo(), during which I notice that I need to build bar(), which refers to foo(). The compiler dies JIT-ing foo() because it's not done yet. Specifically, I'm in the middle of generating one of the BBs of foo(), so it doesn't have a terminating instruction

Hi Duncan, On 7 janv. 2011, at 01:00, Duncan Sands wrote: > LTO is for doing optimizations that are only valid when the module contains > everything that is needed to build the final executable. So adding a flag to > say "not everything is there after all" makes no sense to me. And indeed, everything is there when I call LTO. The flag is not "not everything is there

I found the problem : my code sets JITEmitDebugInfo after creating the JIT. This causes the JITDwarfEmitter DE to not be constructed in the ctor of JITEmitter (JITEmitter.cpp around line 375). Not sure if it's documented anywhere that JITEmitDebugInfo must be set before constructing the JIT, but looking at the code, it makes sense. Easy enough to fix on my side. Christophe On 19 avr. 2011,

Hello, I'd like some advice on a crash that we have observed on MacOSX with the 2.8 and 2.9 releases of LLVM, but not on the top of trunk. The crash is a null-deref in llvm::JITDwarfEmitter::EmitDwarfTable : Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x0000000100852203 in llvm::JITDwarfEmitter::EmitDwarfTable

Hello and happy new year, I'm using LLVM to JIT-compile the XL programming language. I've recently added a whole-program optimization phase that gives excellent results, but I noticed that the StripDeadPrototypesPass was removing all references to my runtime support functions. Apparently, this depends on the oddly-named UnitAtATime parameter. Set it to false. Try again. Suggestion:

I have a simple C++ class that looks like this: struct Foo { Thing *first; Blob *second; unsigned long third; }; Then I have a derived C++ class that look like this: struct Bar : Foo { long long fourth; } I generate JIT code to access 'fourth' from a Foo * as follows: BarPtr = CreateBitCast(FooPtr, BarPtrTy); FourthPtr = CreateConstGEP2_32(BarPtr, 0, 3); FourthValue =

On 5 sept. 2011, at 17:48, Duncan Sands wrote: > since the result of a multiply doesn't depend on the signedness, I find it > strange that your target differentiates between them. What I'm saying is > that if you have (say) two i32 numbers a and b and you do a signed multiply: > c = a *s b > and an unsigned multiply > d = a *u b > then c and d are the same number

On 6 janv. 2011, at 19:00, llvmdev-request at cs.uiuc.edu wrote: >> I'm using LLVM to JIT-compile the XL programming language. I've recently added a whole-program optimization phase that gives excellent results, but I noticed that the StripDeadPrototypesPass was removing all references to my runtime support functions. > > why is that a problem? Because I have pointers to

Hello, We have been investigating a crash in our application that may be related to how stack frames are generated by the JIT. We observe it with LLVM 2.9, but not with LLVM 2.8, everything else being the same. The crash occurs when dynamically generated code calls code that tries to unwind the stack. Here is what the stack trace looks like on MacOSX 10.6 : 0 libSystem.B.dylib