[LLVMdev] Ahoy JIT Users

[Daniel Dunbar]

On Sat, Nov 20, 2010 at 5:38 PM, orthochronous <orthochronous at gmail.com> wrote:
> [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 :-) ?

Nope, I don't think you count. :)

I can only hope you are willing to update your code to track changes
on TOT if you are willing to be as invasively intertwined with LLVM!

 - Daniel

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