Re: [tclquadcode] coro promise alignment - another random idea

[Kevin K. <kev...@gm...>]

I hacked together the patches that:

  - make sure that the target triple and target data layout are set in the
module before any code generation takes place.
  - use the LLVM DataLayout for handling 'sizeof' and 'alignof'

With those in place, I didn't need to tell any lies about the size of the
coroutine promise - CoroSplit finds the correct size and generates correct
code.

There is a companion change in llvmtcl that requires advancing the version
to 3.10 - I've sent a pull request with the changes.

With these changes in place, the mrtest crash is gone - the code worked on
the first try once I'd adapted coro.tcl to use the new 'sizeof' and
'alignof' primitives. All the tests in demos/perftest/tester.tcl pass.

Performance isn't great, but I suspect is adequate.

mrtest - which is really stressing the overhead of recursive procedures,
goes from 960% to only 290%.
qsort - a more realistic example with actual work done in the procedure
before making recursive calls - goes from 244% to 187%.

I'm not positive, but I think I can eliminate one Tcl_NRAddCallback per NRE
procedure invocation, which would help mrtest significantly. I'll put that
one on a back burner for now.

I'm not merging to trunk yet, because I still haven't done invokeExpanded
and invocation of noncompiled commands in the NRE environment. Now that
LLVM is treating my coroutines sanely, that should be a Small Matter of
Programming.

The last five weeks have been quite a slog, but there's light at the end of
the tunnel: my mystery crash, at long last, is gone!




On Mon, Apr 23, 2018 at 6:14 PM, Kevin Kenny <kev...@gm...>
wrote:

> Would it be possible to commit to 'mcjit' or 'simple' before we get to
> 'optimize' and attach the execution engine then? I'm pretty sure that the
> empty string we pass as DataLayout isn't giving the same answers for
> structure offsets.  The LLVM code that's generating the incorrect offset in
> the call thunk is using the data layout to do it - and I think the data
> layout is changing when we bind the execution engine, since that's the
> place where the target data layout is actually known.
>