[LLVMdev] Ahoy JIT Users

[orthochronous]

[Resend: I don't know why Reply-to-all button comes after Repy one]

On Sat, Nov 13, 2010 at 1:42 AM, Daniel Dunbar <daniel at zuster.org> wrote:
> Hi,
>
> I am starting to poke at the LLVM JIT, which seems to be in need of some TLC.
>
> If you are a "sophisticated" JIT user and are using either internal
> APIs (either by integrating with LLVM, or by other C++ tricks), or are
> using obscure or poorly documented public APIs (e.g., why is
> runJITOnFunction exposed?) please make me aware of it!

Rather than "sophisticated", does "completely insane" JIT user count :-) ?

For a while now on and off I've been trying to get a stochastic instruction
scheduling working (for just one function body). The idea is to generate a
reasonable number of correct schedules and time them in a feedback-directed way.
The idea is to just replace code at the scheduling level and piggy
back on lowering, the existing register
allocation, machine code emission, etc. What this wants is hence to be
able to "sit a controller" at the scheduling routine and repeatedly
generate a schedule,
do all the following steps and then run the code and feed the timing result
back to the controller.

The design of the LLVM JIT really doesn't expect anything other than
"single-input/single-output"
processing at any point in the JIT. Changing this properly would be
both a lot of work
and likely of no use to anyone else, so I've been trying to use the nasty
workaround of

* in the controller loop at the scheduler, after generating a candidate schedule
fork() and wait for the child copy, it wait()s.

* the child copy returns from the scheduler and runs the rest of the JIT and
then runs the code in a timing block, returning the time taken.

* the controller picks up this value and uses it to guide new schedule creation.

Amazingly, as far as I can tell if you build llvm with
--enable-threads=no this works.
(If you don't disable threads it looks like it gets stuck in locking
instructions even
thought there's no other threads around.)

I wouldn't remotely expect you to deliberately make sure this continues to work
(it's such a mad thing to do), but just wrote to let you know one thing that is
bieng attempted out-of-tree.

(In case anyone asks why try and do something that so rubs against
llvm's design, it's basically a trade-off. Writing a special code generation
program would make the scheduling easier, but would also require me to
figure out the best way to lower C constructions like "a[i++]" on from the
many possibiliteis on x86 and ARM. It looks like it's marginally less work
to do nasty things to the LLVM codebase than learn and code that up myself.)

Regards,
David Tweed