search for: taodyn

Displaying 15 results from an estimated 15 matches for "taodyn".

Did you mean: taodyne
2010 Feb 03
0
[LLVMdev] Changes in FunctionPassManager constructor
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:...
2010 Feb 03
2
[LLVMdev] Changes in FunctionPassManager constructor
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
2010 Feb 03
0
[LLVMdev] Changes in FunctionPassManager constructor
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 change...
2010 Feb 03
2
[LLVMdev] Changes in FunctionPassManager constructor
>> 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
2010 Feb 03
7
[LLVMdev] Changes in FunctionPassManager constructor
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
2010 Feb 03
0
[LLVMdev] Changes in FunctionPassManager constructor
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...
2010 Feb 03
1
[LLVMdev] Forward references to a function
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
2011 Jan 07
1
[LLVMdev] Marking a function prototype as being "persistent"
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
2011 Apr 19
0
[LLVMdev] Crash in llvm::JITDwarfEmitter::EmitDwarfTable on 2.8 and 2.9 release but not on trunk?
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,
2011 Apr 19
2
[LLVMdev] Crash in llvm::JITDwarfEmitter::EmitDwarfTable on 2.8 and 2.9 release but not on trunk?
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
2011 Jan 06
2
[LLVMdev] Marking a function prototype as being "persistent"
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:
2010 Feb 27
3
[LLVMdev] Object layout bug for C++ derived class with long long integer
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 =
2011 Sep 05
2
[LLVMdev] arithmetical operands signedness
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
2011 Jan 06
2
[LLVMdev] Marking a function prototype as being "persistent"
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
2011 May 30
2
[LLVMdev] Crash in libunwind
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