On Tuesday, 2 February 2021 at 08:11:03 UTC, Max Haughton wrote:
> HOWEVER - all of these changes effectively mean bolting even more flow analysis to the compiler which isn't great given the current coding styles in dmd (It's very "flat" i.e. not much abstraction, and there is a tendency to dump everything in one 10k line file) - this is an easily solvable problem, we just need to be more forward thinking.

There is a need for a new typed intermediate representation that is higher level than the LLVM IR.

One problem is that D allows directly emitting low level constructs.

One way to deal with this is to require all low level code to have a high level counterpart with a version selector.

On Tuesday, 2 February 2021 at 11:14:24 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 2 February 2021 at 08:11:03 UTC, Max Haughton wrote:
>> HOWEVER - all of these changes effectively mean bolting even more flow analysis to the compiler which isn't great given the current coding styles in dmd (It's very "flat" i.e. not much abstraction, and there is a tendency to dump everything in one 10k line file) - this is an easily solvable problem, we just need to be more forward thinking.
>
> There is a need for a new typed intermediate representation that is higher level than the LLVM IR.
>
> One problem is that D allows directly emitting low level constructs.
>
> One way to deal with this is to require all low level code to have a high level counterpart with a version selector.

I'm not convinced that an IR is needed as much as a clearly defined pipeline for the AST as it goes through the compiler, e.g. trying to organise code into passes, at least locally.

On Tuesday, 2 February 2021 at 11:32:53 UTC, Max Haughton wrote:
> I'm not convinced that an IR is needed as much as a clearly defined pipeline for the AST as it goes through the compiler, e.g. trying to organise code into passes, at least locally.

Doing this over the AST is just not a good idea if you care about making it work correctly.

On Tuesday, 2 February 2021 at 11:32:53 UTC, Max Haughton wrote:
> On Tuesday, 2 February 2021 at 11:14:24 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 2 February 2021 at 08:11:03 UTC, Max Haughton wrote:
>>> HOWEVER - all of these changes effectively mean bolting even more flow analysis to the compiler which isn't great given the current coding styles in dmd (It's very "flat" i.e. not much abstraction, and there is a tendency to dump everything in one 10k line file) - this is an easily solvable problem, we just need to be more forward thinking.
>>
>> There is a need for a new typed intermediate representation that is higher level than the LLVM IR.
>>
>> One problem is that D allows directly emitting low level constructs.
>>
>> One way to deal with this is to require all low level code to have a high level counterpart with a version selector.
>
> I'm not convinced that an IR is needed as much as a clearly defined pipeline for the AST as it goes through the compiler, e.g. trying to organise code into passes, at least locally.

One could argue that dmd already has 2 IRs separate from the AST representation:

1. https://github.com/dlang/dmd/blob/master/src/dmd/e2ir.d, https://github.com/dlang/dmd/blob/master/src/dmd/s2ir.d
2. https://github.com/dlang/dmd/blob/7233643c5da2bb531dd0fdec5f823daa12d30217/src/dmd/ob.d#L84-L114


:P

On Wednesday, 3 February 2021 at 08:58:18 UTC, Petar Kirov [ZombineDev] wrote:
> On Tuesday, 2 February 2021 at 11:32:53 UTC, Max Haughton wrote:
>> On Tuesday, 2 February 2021 at 11:14:24 UTC, Ola Fosheim Grøstad wrote:
>>> [...]
>>
>> I'm not convinced that an IR is needed as much as a clearly defined pipeline for the AST as it goes through the compiler, e.g. trying to organise code into passes, at least locally.
>
> One could argue that dmd already has 2 IRs separate from the AST representation:
>
> 1. https://github.com/dlang/dmd/blob/master/src/dmd/e2ir.d, https://github.com/dlang/dmd/blob/master/src/dmd/s2ir.d
> 2. https://github.com/dlang/dmd/blob/7233643c5da2bb531dd0fdec5f823daa12d30217/src/dmd/ob.d#L84-L114
>
>
> :P

You could but you'd be wrong. The "IR" ob.d uses doesn't actually track enough information to do proper error messages, and I've tried.