search for: r88984

...the large code model. (llc -code-model=large) > If that also causes tail calls to break, then I did something wrong in > fixing far calls in the JIT. Jeffrey, I took a closer look at this now, and all the TCO-related weirdness I see in the Pure interpreter is indeed related to your commit in r88984 ("Make X86-64 in the Large model always emit 64-bit calls"). Up to and including r88983, Pure passes all checks (at least with eager compilation, see below), with r88984 and later more than half of the checks fail. This only happens when using dynamic compilation. As I reported earlier, b...

Hi, On Tue, Dec 15, 2009 at 9:25 PM, Jeffrey Yasskin <jyasskin at google.com>wrote: > On Tue, Dec 15, 2009 at 1:05 AM, Zoltan Varga <vargaz at gmail.com> wrote: > > Hi, > > > > After this commit: > > http://llvm.org/viewvc/llvm-project?view=rev&revision=88984 > > > > the X86 JIT no longer emits calls using call <ADDR>, but always uses

On Tue, Dec 15, 2009 at 1:05 AM, Zoltan Varga <vargaz at gmail.com> wrote: > Hi, > > After this commit: > http://llvm.org/viewvc/llvm-project?view=rev&revision=88984 > > the X86 JIT no longer emits calls using call <ADDR>, but always uses mov > REG, <ADDR>, call *REG. That should only be the x86-64 JIT. If the x86-32 JIT does that, it's definitely a

Hi, After this commit: http://llvm.org/viewvc/llvm-project?view=rev&revision=88984 the X86 JIT no longer emits calls using call <ADDR>, but always uses mov REG, <ADDR>, call *REG. This causes problems for the usage of LLVM in JITs since the JIT can no longer patch the callsite after the callee have been compiled. According to the comments for the commit, this was done to fix the

...-code-model=large) >> If that also causes tail calls to break, then I did something wrong in >> fixing far calls in the JIT. > > Jeffrey, I took a closer look at this now, and all the TCO-related > weirdness I see in the Pure interpreter is indeed related to your commit > in r88984 ("Make X86-64 in the Large model always emit 64-bit calls"). > Up to and including r88983, Pure passes all checks (at least with eager > compilation, see below), with r88984 and later more than half of the > checks fail. This only happens when using dynamic compilation. As I >...

On Sun, Nov 29, 2009 at 2:19 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > Jon Harrop wrote: >> I've come up with the following minimal repro that segfaults on my machine: > > Jon, were you able to resolve this? > > FWIW, TOT is causing all kinds of weird segfaults related to tail calls > in my Pure interpreter, too (at least on x86-64). In my case these

Jon Harrop wrote: > I've come up with the following minimal repro that segfaults on my machine: Jon, were you able to resolve this? FWIW, TOT is causing all kinds of weird segfaults related to tail calls in my Pure interpreter, too (at least on x86-64). In my case these seem to be limited to the JIT, however (batch-compiled Pure programs via opt+llc all work fine, even with TCO), so