December 17, 2020
On Thursday, 17 December 2020 at 16:02:05 UTC, Guillaume Piolat wrote:
> On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:
>>
>> And yet why does DMD suck at optimising code? Because a freedom to do something that nobody has the resources to do is next to useless.
>
> DMD builds fast, and is small, it has some value and it would be more used if you could somehow rely on code generation. (for example, raylib ships with a tinycc compiler for speed of compile-run loop)
>
> However I think an ARM backend may be just too much debt when we don't have a reliable x86 backend in DMD. And I don't know why it's the case, it has been a constant over years.
>
> (for info: the particular issue that irks me is https://issues.dlang.org/show_bug.cgi?id=21474)
>
> I'd be really wary to release something built with DMD and optimizations on.
> This is not _only_ about speed imho.

If we really wanted an ARM backend in DMD it would probably be simpler to just build one from scratch. The basic optimizations needed to get vaguely acceptable performance for a fast/test build aren't all that complicated, especially if you build SSA (massively simplfies quite a few optimizations). It's still a big job, but it would also probably be useful to speed up CTFE as well (having a clean and reusable IR -> JIT).

The current backend is fairly unwieldy, true, but it's also very old and could be a lot smaller now we have things like ranges (or even templates) - as with many things in the compiler it doesn't/can't use modern D for various reasons.

For an empirical guess of how big a backend would be - cranelift is a modern (not just SSA) backend aimed at build times rather than runtime efficiency, and it clocks in (cranelift/codegen) at roughly 90k lines (the whole project warts and all is 130k). The current dmd backend is 97k. We could be significantly more concise because we have better metaprogramming - i.e. LLVM has a huge amount of boilerplate and DSLs that could be done fairly easily either as metaprogamming or mixin DSLs.

Is it worth it? No idea, but it isn't a totally unrealistic proposition (More realistically would be a dub project being merged in, I have a few rubbish backend projects on various computers of mine but none are remotely worth publishing).


December 17, 2020
On Thursday, 17 December 2020 at 08:52:40 UTC, Walter Bright wrote:
> On 12/16/2020 2:33 AM, Max Haughton wrote:
>> I know I just like the dmd-style ones, it feels much more ergonomic than the equivalent in C++. I'm not a huge fan of GCC style asm, but ultimately I guess I'm bikeshedding.
>
> The dmd-style ones hearken back to the good ole DOS days, where MASM matched the Intel documentation. It's an evolved version of the inline assembler used by Digital Mars C, which matches MASM and Intel.
>
> Intel has kept the same syntax ever since, and DMD's inline asm has kept on matching it.
>

Though one critique would be that DMD is always behind on instruction set support, as of writing I don't think even AVX-512F can be used yet.
December 17, 2020
On 12/17/2020 2:41 PM, Iain Buclaw wrote:
> Though one critique would be that DMD is always behind on instruction set support, as of writing I don't think even AVX-512F can be used yet.

Intel keeps moving the goal posts :-)

Sometimes others have added such support, so it's not impossible.
December 17, 2020
On 12/17/2020 2:02 AM, claptrap wrote:
> And lets be honest if LLVM doesnt support it, it's pretty small potatoes, who's going to go to that kind of effort to add some niche architecture to DMD?

Win64 was never small potatoes.

Besides, nothing is impairing using LDC.
December 17, 2020
On 12/17/2020 8:02 AM, Guillaume Piolat wrote:
> (for info: the particular issue that irks me is https://issues.dlang.org/show_bug.cgi?id=21474)
> 
> I'd be really wary to release something built with DMD and optimizations on.
> This is not _only_ about speed imho.

That was reported 5 days ago, give me a chance!

There are hardly any outstanding optimization bugs in DMD.

That said, I'll take a look at this issue.

BTW, please tag code gen issues with the `backend` keyword, else I'm apt to miss it.
December 17, 2020
On Thursday, 17 December 2020 at 23:22:20 UTC, Walter Bright wrote:
>
> BTW, please tag code gen issues with the `backend` keyword, else I'm apt to miss it.

Got 3 tagged, I expect a bit more issues when D_SIMD will be used :)
December 18, 2020
On Thursday, 17 December 2020 at 23:16:33 UTC, Walter Bright wrote:
> On 12/17/2020 2:02 AM, claptrap wrote:
>> And lets be honest if LLVM doesnt support it, it's pretty small potatoes, who's going to go to that kind of effort to add some niche architecture to DMD?
>
> Win64 was never small potatoes.

So some years ago DMD had a single target that LLVM did not, and how does it look today?


December 17, 2020
On 12/17/2020 3:35 PM, Guillaume Piolat wrote:
> On Thursday, 17 December 2020 at 23:22:20 UTC, Walter Bright wrote:
>>
>> BTW, please tag code gen issues with the `backend` keyword, else I'm apt to miss it.
> 
> Got 3 tagged, I expect a bit more issues when D_SIMD will be used :)

So I see!

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=backend%2C%20&keywords_type=allwords&list_id=234080&query_format=advanced
December 19, 2020
On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright wrote:
> On 12/14/2020 1:57 AM, Abdulhaq wrote:
>> DMD is Walter's baby and he's going to continue with that, having power over it is secondary to that.
>> 
>> D Foundation of course want to retain control over what they have built, it's years and years of their hard work, decades even. Why should they give control to someone else and why think that that other group would do any better? Arguably it would be irresponsible to do that.
>
>
> Having DMD means we can support whatever target we want to, we are not constrained by a community we don't really have a voice in.

Not really... You can add custom targets to LLVM. You have the whole framework to back you up so you aren't reimplementing it.

> For example, DMD moved to support Win64 years before LLVM supported it.

So you only added 1 target? When is ARM64 going to be added? LLVM has had it for years (along with many other architectures).

You are also comparing apples to oranges. What LLVM achieves is implementing *everything* for windows. You can literally replace MSVC with LLVM CLang. DMD implements a very small subset of that. LLVM supporting Win64 is much much more impressive than DMD supporting it.

When you use LLVM it's not "theirs". That's the whole point of the community being open source. It is "ours". I feel that's part of what is wrong with this community.

> I don't see how LDC and GDC are impaired in any way by DMD.

Maybe you should look into the development of LDC and GDC and you'll see the cracks.



December 19, 2020
On 12/18/2020 8:10 PM, Kali wrote:
> So you only added 1 target?
The backend targets:

* 16 bit DOS
* 16 bit Windows (yes, it's different)
* 286 protected mode
* 386 DOS extenders
* OS/2

Yes, the above are obsolete. But it shows the adaptability of the backend design.

* 32 bit Windows
* 64 bit Windows
* OSX 32/64, FreeBSD 32/64, Linux 32/64

There are obsolete 68000 and PowerPC targets written by others.

There's a partial 32 bit ARM target written by another.

Win64 is only one target, sure, but it was a crucial one for D.