www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [SAoC 2021] Replace druntime Hooks with Templates: Milestone 1, Week 1

reply Teodor Dutu <teodor.dutu gmail.com> writes:
Hi,

My project wants to replace dmd hooks to druntime functions such 
as `_d_arrayctor`, `_d_arrayappendT` and `_d_arraycatT` with 
templates. This will make lowerings to these functions faster at 
runtime, as their templated versions will not require all the 
indirection used by the hooks. Speaking of indirection, at the 
end of this project, the `TypeInfo` class will be removed as all 
its information will be used at compile time, when instantiating 
the aforementioned templates. As a result, the maintainability of 
the compiler will be improved as lowerings will now take place in 
the semantic analysis phase, as opposed to the IR phase (where 
the hooks are currently present).

Dan Printzell worked on this in the past, as part of his [GSoC 
2019 project](https://github.com/Vild/GSOC2019). I'll be picking 
up the work that he left and then I'll continue with the 
remaining hooks.

During my first week, I worked on finishing Dan's 
[PR](https://github.com/dlang/dmd/pull/10102) for the 
`_d_array{,set}ctor` functions:
- My mentors (Eduard Stăniloiu and Răzvan Nițu) and I fixed some 
of [Dan's 
logic](https://github.com/dlang/dmd/blob/e7c81c3021f5948a2a743c0926969f5370178f28/src/dmd/expressi
nsem.d#L9008-L9016) for choosing when to perform the lowering or not. We
skipped lowering in expressionsem.d for snippets like `S[3] arr = [S(1), S(2),
S(3)];`, as e2ir.d already handles such cases more elegantly.
- The tests that are currently failing are runnable/testassign.d 
and compilable/interpret3.d. For example, runnable/testassign.d 
fails because in expressions like `funcVal(a = b)` the temporary 
variable used as the actual argument for `funcVal` is not lowered 
to use `_d_arraysetctor`, when it actually should. I am still 
working on fixing it.

Thanks,
Teodor
Sep 23 2021
next sibling parent reply kinke <noone nowhere.com> writes:
On Thursday, 23 September 2021 at 15:15:32 UTC, Teodor Dutu wrote:

 We skipped lowering in expressionsem.d for snippets like `S[3] 
 arr = [S(1), S(2), S(3)];`, as e2ir.d already handles such 
 cases more elegantly.


This is bad news for all non-DMD compilers, as e2ir.d is DMD 
only, and LDC and GDC would have to duplicate thew lowerings in 
the glue layer now. Please don't.
Sep 23 2021
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Thursday, 23 September 2021 at 16:06:57 UTC, kinke wrote:

 On Thursday, 23 September 2021 at 15:15:32 UTC, Teodor Dutu 
 wrote:

 We skipped lowering in expressionsem.d for snippets like `S[3] 
 arr = [S(1), S(2), S(3)];`, as e2ir.d already handles such 
 cases more elegantly.


 This is bad news for all non-DMD compilers, as e2ir.d is DMD 
 only, and LDC and GDC would have to duplicate thew lowerings in 
 the glue layer now. Please don't.


Just to clarify, there is no lowering happening in e2ir. What 
happens right now (before replacing the hook with template) is 
that in some situations the hook is bypassed (i.e. no call is 
made to druntime). We mimicked this logic in our implementation.

To clarify:

S[1] a = [S(1)];

would be lowered to:

_d_arrayCtor(a, [S(1)]);

which in turn gets rewritten to:

S[1] __arraystack_literal = [S(1)];
_d_arratCtor(a, __arraystack_literal);

Now, the first line, if we are not careful, will be lowered
to _d_arrayCtor hence the infinite loop.

Looking at the current state of e2ir [1], we saw that in the case
where rhs is an array literal the lowering is not performed
anymore. Instead, the literal is assigned element-wise.

What Teo meant is that in this situation we are not lowering to
_d_arrayctor, rather we just let the compiler handle the case as
it did up until now.

[1] https://github.com/dlang/dmd/blob/master/src/dmd/e2ir.d#L2519
Sep 23 2021
parent kinke <noone nowhere.com> writes:
On Thursday, 23 September 2021 at 16:30:57 UTC, RazvanN wrote:

 Just to clarify, there is no lowering happening in e2ir. What 
 happens right now (before replacing the hook with template) is 
 that in some situations the hook is bypassed (i.e. no call is 
 made to druntime). We mimicked this logic in our implementation.


Okay that sounds better, thx for clarifying.
Sep 23 2021
prev sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Thursday, 23 September 2021 at 15:15:32 UTC, Teodor Dutu wrote:

 Speaking of indirection, at the end of this project, the 
 `TypeInfo` class will be removed as all its information will be 
 used at compile time.


With what it will be replaced then?

Will I be able to do this:

```
int[] id;

typeid(id).writeln;
```

The typeinfo itself would be best to remain imho. Though 
functionality that is only related to those hooks should be 
removed.

Best regards,
Alexandru.
Sep 23 2021
parent reply Teodor Dutu <teodor.dutu gmail.com> writes:
On Thursday, 23 September 2021 at 17:04:51 UTC, Alexandru 
Ermicioi wrote:

 On Thursday, 23 September 2021 at 15:15:32 UTC, Teodor Dutu 
 wrote:

 Speaking of indirection, at the end of this project, the 
 `TypeInfo` class will be removed as all its information will 
 be used at compile time.


 With what it will be replaced then?

 Will I be able to do this:

 ```
 int[] id;

 typeid(id).writeln;
 ```

 The typeinfo itself would be best to remain imho. Though 
 functionality that is only related to those hooks should be 
 removed.


Yes, you're right. What I meant to say is that `TypeInfo` will 
only be removed from the hooks' ecosystem (together with the 
hooks themselves) and in its entirety.

Teodor
Sep 23 2021
parent reply Teodor Dutu <teodor.dutu gmail.com> writes:
On Thursday, 23 September 2021 at 18:28:31 UTC, Teodor Dutu wrote:

 On Thursday, 23 September 2021 at 17:04:51 UTC, Alexandru 
 Ermicioi wrote:

 On Thursday, 23 September 2021 at 15:15:32 UTC, Teodor Dutu 
 wrote:

 Speaking of indirection, at the end of this project, the 
 `TypeInfo` class will be removed as all its information will 
 be used at compile time.


 With what it will be replaced then?

 Will I be able to do this:

 ```
 int[] id;

 typeid(id).writeln;
 ```

 The typeinfo itself would be best to remain imho. Though 
 functionality that is only related to those hooks should be 
 removed.


 Yes, you're right. What I meant to say is that `TypeInfo` will 
 only be removed from the hooks' ecosystem (together with the 
 hooks themselves) ...


... and **not** in its entirety.

Teodor
Sep 23 2021
parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Thursday, 23 September 2021 at 18:38:47 UTC, Teodor Dutu wrote:

 Yes, you're right. What I meant to say is that `TypeInfo` will 
 only be removed from the hooks' ecosystem (together with the 
 hooks themselves) ...


 ... and **not** in its entirety.

 Teodor


Awesome, keep up doing the good work!

Regards,
Alexandru.
Sep 24 2021