These are chat archives for dropbox/pyston
callCLFunc@objmodel.cpp, after calling the compiled function, we have the assertion
ASSERT(!PyErr_Occurred(), "%p", chosen_cf->code);. I think that should be
ASSERT(!PyErr_Occurred() || S == CAPI, "%p", chosen_cf->code);?
r != NULLpath
PyErr_Occurred()true before the call to
looks like llvm is not very smart with our current pass pipeline:
mov %rax,-0x248(%rbp) cmpq $0x0,-0x248(%rbp) je 0x7f114504a17d <generate_tokens_e3_1+12669>
mov %rax,-0x208(%rbp) mov -0x208(%rbp),%rax
mov $0x1,%eax mov %rax,-0x1f8(%rbp) mov $0x1,%eax mov %rax,-0x238(%rbp)
I'am still tracking down the minimal number of passes we have to add to get ride of all this unnecessary code.
But just for the lols one more: that is how we currently clear a region of memory
xorps %xmm0,%xmm0 movaps %xmm0,-0xe0(%rbp) xorps %xmm0,%xmm0 movaps %xmm0,-0xf0(%rbp) ... same pattern repeats another >10 times
Looks like llvm doesn't trust xmm0 very much and makes sure its really stays at
So it still unclear to me why llvm generates sometimes this stupid pattern and sometimes not:
good version: xorps %xmm0,%xmm0 movaps %xmm0,-0xd0(%rbp) movaps %xmm0,-0xe0(%rbp) movaps %xmm0,-0xf0(%rbp) ...
switching to the greedy reg alloc removes most of the stupid code and gives a significant perf improvement. (But makes my code crash for some benchmarks...)
ok another run and I'm seeing again a pattern of
mov $0x0,%ecx mov %rcx,-0x268(%rbp) mov $0x0,%ecx mov %rcx,-0x260(%rbp) ...repeated about 10 times...
something is really odd... but enough for today...