On 6/7/2022 6:16 AM, Ali Çehreli wrote:
> Anything more to the story? You should get more sales when they hopefully published the explanation with an apology. (?)

They refused to publish a correction. They didn't give a fig, because I wasn't Microsoft and a big advertiser.

On 6/7/2022 1:44 AM, max haughton wrote:
> Unfortunately the dmd optimizer and inliner are somewhat buggy so most "enterprise" users actually avoid them like the plague or have fairly hard-won scars. At least one of our libraries doesn't work with -O -inline, many others cases have similar issues.

I am not aware of this. Bugzilla issues, please?


> optimization isn't just about adding special cases, the sheer amount of optimizations dmd would have to learn on top of an already horrific codebase in the backend (note that to start with the register allocator is pretty bad, but isn't easily replaced) means while it's technically possible it's practically just not realistic.

Everybody says that, but I just go and add the optimizations people want anyway.


> The IR used by the backend is also quite annoying to work with. SSA is utterly dominant in compilers (and has been since the late 90s) for a reason. It's not it's fault because it's so old but the infrastructure and invariants you get from it are just nothing even close to being easy to work on versus even GCC before they realized LLVM was about to completely destroy them (almost no one does new research with GCC anymore mostly because LLVM is easier to work on).

Triples *are* SSA, in that each node can be considered an assignment to a temporary.


> This IR and the lack of structure around operations on it is why dmd has so many bugs wrt things like SIMD code generation.

SSA has nothing whatsoever to do with SIMD code generation.

The SIMD problems have all turned out to be missed special cases (SIMD is very complex). If you look at the PRs I made to fix them, they're all small. Not indicative of any fundamental problem.

I thought I fixed the SIMD issues you were having? What is left undone?

On Tuesday, 7 June 2022 at 18:22:55 UTC, Walter Bright wrote:
> On 6/7/2022 6:16 AM, Ali Çehreli wrote:
>> Anything more to the story? You should get more sales when they hopefully published the explanation with an apology. (?)
>
> They refused to publish a correction. They didn't give a fig, because I wasn't Microsoft and a big advertiser.

What was the magazine? I'd like to search and read them.

By the way, today those reviewers would have a nice lesson from the internet, like we see from time to time and those people make dumb affirmations/mistakes.

Matheus.

On Tuesday, 7 June 2022 at 18:27:32 UTC, Walter Bright wrote:
> On 6/7/2022 1:44 AM, max haughton wrote:
>> Unfortunately the dmd optimizer and inliner are somewhat buggy so most "enterprise" users actually avoid them like the plague or have fairly hard-won scars. At least one of our libraries doesn't work with -O -inline, many others cases have similar issues.
>
> I am not aware of this. Bugzilla issues, please?

The main one we hit is NRVO issues with -inline. Mathias Lang also me showed an issue with it but I can't remember which project it was.

They should already be filed I can find the  issues if required but they should just a bugzilla search away.

>
>> optimization isn't just about adding special cases, the sheer amount of optimizations dmd would have to learn on top of an already horrific codebase in the backend (note that to start with the register allocator is pretty bad, but isn't easily replaced) means while it's technically possible it's practically just not realistic.
>
> Everybody says that, but I just go and add the optimizations people want anyway.

Realistic for anyone other than you then ;)

With the register allocator as a specific example my attention span is rather short but it was pretty impenetrable when I tried to explain to myself what algorithm it actually uses.

>
>> The IR used by the backend is also quite annoying to work with. SSA is utterly dominant in compilers (and has been since the late 90s) for a reason. It's not it's fault because it's so old but the infrastructure and invariants you get from it are just nothing even close to being easy to work on versus even GCC before they realized LLVM was about to completely destroy them (almost no one does new research with GCC anymore mostly because LLVM is easier to work on).
>
> Triples *are* SSA, in that each node can be considered an assignment to a temporary.

Meanwhile I can assign to a variable in a loop? Or maybe you aren't supposed to be able to and that was a bug in some IR I generated? The trees locally are SSA but do you actually enforce SSA in overall dataflow?

Similarly SSA applies across control flow boundaries, phi nodes?

Anyway my point about SSA is more that one of the reasons it's prevalent is that it makes writing passes quite a lot easier.

Implementing address sanitizer should be a doddle but it was not with the dmd backend so I had to give up.

This is actually a really useful feature that we already link with at the moment on Linux so I can tell you exactly the lowering needed if required. You'll be able to do it within minutes I'm sure but I can't devote the time to working out and testing all the bitvectors for the DFA etc.

>
>> This IR and the lack of structure around operations on it is why dmd has so many bugs wrt things like SIMD code generation.
>
> SSA has nothing whatsoever to do with SIMD code generation.

In the same way that structured programming has nothing to do with avoiding bugs. I'm not saying it's impossible to do without SSA it's just indicative of an IR that isn't very good compared to even simple modern ones.

Within the backend I actually do think there is a elegant codebase trying to escape just that to achieve that it would need a few snips in the right place to make it feasible to extract.

> The SIMD problems have all turned out to be missed special cases (SIMD is very complex). If you look at the PRs I made to fix them, they're all small. Not indicative of any fundamental problem.

They look like special cases, and maybe they are fundamentally, but other compilers simply do not have this rate of mistakes when it comes to SIMD instruction selection or code generation.

It just smells really bad compared to GCC. LLVM tries to be fancy in this area so I wouldn't copy.

I want to help with this and just today I have fixed a backend issue but I just wanted to say some things about it.