search for: dinechin

...... I guess the source code snippets are updated automagically. As a result, the code shown there as an example will NOT compile on anything but a most recent LLVM, i.e. it will not work if you install LLVM with apt-get or MacPorts. I don't think that's desirable. Opinions? Christophe de Dinechin

Hi Christophe, So this is a pain, but we are dealing with a pre-release. Until the 2.7 freeze the source should continue to churn. Regards Garrison On Feb 3, 2010, at 11:34, Christophe de Dinechin wrote: > 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 ModuleP...

...ty. Garrison On Feb 3, 2010, at 12:11, Garrison Venn wrote: > Hi Christophe, > > So this is a pain, but we are dealing with a pre-release. Until the 2.7 freeze the source should continue to churn. > > Regards > > Garrison > > On Feb 3, 2010, at 11:34, Christophe de Dinechin wrote: > >> 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 FunctionPassManag...

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

...tructed 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, at 17:38, Christophe de Dinechin wrote: > 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...

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 modifi...

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. &gt...

On Feb 3, 2010, at 8:34 AM, Christophe de Dinechin 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 since then, when the...

On 25 nov. 2010, Renato Golin <rengolin at systemcall.org> wrote: > I don't see how you can have dominance between a normal block and a > cleanup block. Clean-up landing pads should never use user code (since > they don't exist in userland). [...] > In essence, in compiler generated landing pads, you should never > generate a use of user values. But if XYZ is user

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

Hi Christophe, On 05/09/11 18:35, Christophe de Dinechin wrote: > > 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...

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,...

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

>> 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

...al crash could occur if the personality function associated with the generated code is not behaving properly. Hopefully others will respond to rectify my thoughts and therefore help you out. :-) I'm guessing more data will be needed though. Garrison On May 30, 2011, at 5:45, Christophe de Dinechin wrote: > 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 cod...

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

...nux.ibm.com; heiko.carstens at de.ibm.com; gor at linux.ibm.com; > > borntraeger at de.ibm.com; akrowiak at linux.ibm.com; freude at linux.ibm.com; > > lingshan.zhu at intel.com; Ido Shamay <idos at mellanox.com>; > > eperezma at redhat.com; lulu at redhat.com; christophe.de.dinechin at gmail.com; > > kevin.tian at intel.com > > Subject: Re: [PATCH V3 4/7] mdev: introduce device specific ops > > > > On Wed, 16 Oct 2019 05:50:08 +0000 > > Parav Pandit <parav at mellanox.com> wrote: > > > > > Hi Alex, > > > > &g...

...included in the PACT-2016 conference proceedings. The content, however, can be included in a future submission to other conferences or journals. SELECTION COMMITTEE Chair: Erik Altman, IBM T.J. Watson Research Center Committee Members: Christoph Dubach, University of Edinburgh Benoit Dupont de Dinechin, Kalray Kemal Ebcioglu, Global Supercomputing Lieven Eeckhout, University of Ghent R. Govindarajan, Indian Institute of Science Boris Grot, University of Edinburgh Christoph Kessler, Linkoping University Dorit Nuzman, Intel Rodric Rabbah, IBM Ronny Ronen, Intel Xipeng Shen, North Carolina State Uni...

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

On Fri, Oct 05, 2018 at 04:38:11PM +0200, Christophe de Dinechin wrote: > > > > On 5 Oct 2018, at 14:51, Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > The feature allows the guest request an EDID blob (describing monitor > > capabilities) for a given scanout (aka virtual monitor connector). > > > > It bri...