Hi all

Announce thread is here: https://forum.dlang.org/post/nkyvlwboafmhapmbesss@forum.dlang.org

Is someone interested in this?
I'd like to hear some opinions/suggestions about it.
And I'll probably propose some small refactorings into ldc compiler.

On Tuesday, 22 November 2016 at 17:24:16 UTC, Ivan Butygin wrote:
> Hi all
>
> Announce thread is here: https://forum.dlang.org/post/nkyvlwboafmhapmbesss@forum.dlang.org
>
> Is someone interested in this?
> I'd like to hear some opinions/suggestions about it.
> And I'll probably propose some small refactorings into ldc compiler.

Had already seen it. It's awesome :)

Hi Ivan,

seems pretty cool and there are surely quite a few use cases for it, but I currently lack the time to check and comment on the code. Do you plan to eventually upstream it into LDC?

On Wednesday, 23 November 2016 at 09:12:15 UTC, kink wrote:
> Hi Ivan,
>
> seems pretty cool and there are surely quite a few use cases for it, but I currently lack the time to check and comment on the code. Do you plan to eventually upstream it into LDC?

Thanks

It would be great to have this feature in the official LDC. But before that I wanted to discuss and stabilize features and API.

On Wednesday, 23 November 2016 at 17:18:05 UTC, Ivan Butygin wrote:
> On Wednesday, 23 November 2016 at 09:12:15 UTC, kink wrote:
>> Hi Ivan,
>>
>> seems pretty cool and there are surely quite a few use cases for it, but I currently lack the time to check and comment on the code. Do you plan to eventually upstream it into LDC?
>
> Thanks
>
> It would be great to have this feature in the official LDC. But before that I wanted to discuss and stabilize features and API.

Totally epic! Please make this happen!

How about "@jit" instead of "@runtimeCompile"?

Would it work for blocks or only functions?

@jit
{
}

On Thursday, 24 November 2016 at 17:37:01 UTC, Daniel N wrote:
> On Wednesday, 23 November 2016 at 17:18:05 UTC, Ivan Butygin wrote:
>> On Wednesday, 23 November 2016 at 09:12:15 UTC, kink wrote:
>>> Hi Ivan,
>>>
>>> seems pretty cool and there are surely quite a few use cases for it, but I currently lack the time to check and comment on the code. Do you plan to eventually upstream it into LDC?
>>
>> Thanks
>>
>> It would be great to have this feature in the official LDC. But before that I wanted to discuss and stabilize features and API.
>
> Totally epic! Please make this happen!
>
> How about "@jit" instead of "@runtimeCompile"?
>
> Would it work for blocks or only functions?
>
> @jit
> {
> }

Actual attribute name is a subject for discussion because I'm pretty bad at naming things :)
Doing this for blocks will complicates implementation a LOT not to mention it will require changes in frontend I wanted to avoid. But it should be possible to do this for nested functions (I didn't tried this yet).

On Thursday, 24 November 2016 at 18:34:51 UTC, Ivan Butygin wrote:
>
> Actual attribute name is a subject for discussion because I'm pretty bad at naming things :)
> Doing this for blocks will complicates implementation a LOT not to mention it will require changes in frontend I wanted to avoid. But it should be possible to do this for nested functions (I didn't tried this yet).

I suspected that was the case. :)

Good choice, much better with a smaller patch-set which can be merged more easily. More features can always be added later, if there's real demand.

There are a lot of questions how this feature should interact with PGO/coverage analysis/debug info generation.

And current prototype is very hacky.
I generate special thunk for runtime compiled function to call it instead of original function:
https://github.com/Hardcode84/ldc/commit/ccbb40eae0bef263b70ff54181ca04f62dbfd9a9#diff-e48140f4aefdf187e6406905c4c9e84cR76
https://github.com/Hardcode84/ldc/commit/ccbb40eae0bef263b70ff54181ca04f62dbfd9a9#diff-92cc634886bf8dc6f1a79b6177ba0fd2R535

To replace calls I first created wrapper instead of accessing getIrFunc()->func directly:
https://github.com/Hardcode84/ldc/commit/b92ef902cc27ad062698ab178d1a985f7ec8d332

And then just do a very stupid hack to replace returned function:
https://github.com/Hardcode84/ldc/commit/ccbb40eae0bef263b70ff54181ca04f62dbfd9a9#diff-51d8532dc9b4eedb04dfd406b3aa3bf1R59

I need some more intelligent way to replace functions with thunks.

On Thursday, 24 November 2016 at 20:00:11 UTC, Ivan Butygin wrote:
> There are a lot of questions how this feature should interact with PGO/coverage analysis/debug info generation.

I would postpone these 3 issues, and just disable them for now if it's too much work. Nice topics for future (!) work. :-)
Can @jit functions write to normal global variables? (DMD-style coverage is just that; PGO is more involved because LLVM creates the IR instructions for that)

> I need some more intelligent way to replace functions with thunks.

Looking at what you've achieved, I think you are more than intelligent enough to come up with a great solution! :-)

Upon emitting a call to a function, you can detect that the function is "@jit" and instead emit a functionptr call, right?
I think all that's needed is adding that functionality to `DValue *call(...)` in gen/toir.cpp. It already has code for indirect calls; so probably all you have to do is add a bit of code to load from the function pointer that is written to by `rtCompileProcess`.

I didn't check but if there isn't already, the functionptr should be initialized with the address of a function that errors and tells the user that the function is not yet compiled, _or_ a function that starts JIT compilation and calls the desired function afterwards.

(Hop on Gitter for an easier discussion of things :-)

-Johan