August 06

On Saturday, 6 August 2022 at 08:04:37 UTC, rempas wrote:

>

On Saturday, 6 August 2022 at 07:10:43 UTC, user1234 wrote:

>

I suggested to experiment MIR like that, it was not a proposal on the final design.
Experimenting using LLVM IR could be useful to determine if working seriously on the project is worth.

Anyway if you want to put your hand in the hard stuff from the start I think you have two options.

  1. Create an AST visitor that generate MIR format after DMDFE semantics
  2. Create the MIR representation after the part of the backend that generate DMD IR (s2ir, e2ir, etc.) has run.

The second option might be easier because the production will most of the time map 1:1 to a MIR equivalent.

The first option is IMO would be harder because of forward references and imports. and even without that, that would require to split visiting in several passes (decls, aggregate members, function headers, function bodies)

Thank you for the info! The thing is (and why I make the question originally)
how do I find info about how to get started? I don't even know how DMD
works and how it's IR works. Does DMD's frontend parses the text and then
outputs something like LLVM-IR (but for DMD) which we can take and then
translate it to the final backend that we need (in our case mir) or something
else? That's what I want to know. So yeah, is there a legit documentation or
something or do backend developers have to guess how things work and do
"hacking"?
[...]

You'll have to read DMD code to get familiar with its code base (another way in the past was fixing bugs, unfortunately there are not much easy ones anymore). Fortunately you'll dont have to understand the whole thing. In a first time I'd suggest you to follow the lifetime of one particular construct and that for each big family of node.

Choose

  • a Type (maybe the one for int)
  • a Statement (maybe the ReturnStatement)
  • a Declaration (the FunctionDeclaration)
  • an Expression (maybe the IntegerExp).

Try to follow what is happening during the different passes.
That way you'll have a good idea of what the compiler does for

int i(){return 0;}

and where you could generate MIR stuff.

August 06

On Saturday, 6 August 2022 at 08:31:16 UTC, user1234 wrote:

>

You'll have to read DMD code to get familiar with its code base (another way in the past was fixing bugs, unfortunately there are not much easy ones anymore). Fortunately you'll dont have to understand the whole thing. In a first time I'd suggest you to follow the lifetime of one particular construct and that for each big family of node.

Choose

  • a Type (maybe the one for int)
  • a Statement (maybe the ReturnStatement)
  • a Declaration (the FunctionDeclaration)
  • an Expression (maybe the IntegerExp).

Try to follow what is happening during the different passes.
That way you'll have a good idea of what the compiler does for

int i(){return 0;}

and where you could generate MIR stuff.

Thanks my friend! I'll try to read and understand the code and If I end up been
able to create anything, I'll shared it here! Have a great day!

August 06
On Saturday, 6 August 2022 at 07:39:36 UTC, Walter Bright wrote:
>
> The dmd backend is already in D :-)
>
> But since it's all Boost Licensed, anyone can use 0..100% of it for their own backend project. No asking is required.
>
> Have fun!

But where is inliner located? I read that several other languages (Jai, Zig) are trying to make their own x86_64 backends because GCC and LLVM are too slow. If DMD backend had its IR well documented and inliner implemented not in the frontend I could see a future where it could be used by other languages.
August 06
On Saturday, 6 August 2022 at 07:39:36 UTC, Walter Bright wrote:
>
> The dmd backend is already in D :-)
>
> But since it's all Boost Licensed, anyone can use 0..100% of it for their own backend project. No asking is required.
>
> Have fun!

Thank you! It just happened that I missed this reply and wouldn't
even see it if it wasn't for another reply that quotes it...
August 06
On Saturday, 6 August 2022 at 18:02:34 UTC, welkam wrote:
> But where is inliner located? I read that several other languages (Jai, Zig) are trying to make their own x86_64 backends because GCC and LLVM are too slow. If DMD backend had its IR well documented and inliner implemented not in the frontend I could see a future where it could be used by other languages.

DMD's inliner is being moved to the backend:

https://github.com/dlang/dmd/pull/14194
August 06
On Saturday, 6 August 2022 at 18:35:18 UTC, Paul Backus wrote:
> On Saturday, 6 August 2022 at 18:02:34 UTC, welkam wrote:
>> But where is inliner located? I read that several other languages (Jai, Zig) are trying to make their own x86_64 backends because GCC and LLVM are too slow. If DMD backend had its IR well documented and inliner implemented not in the frontend I could see a future where it could be used by other languages.
>
> DMD's inliner is being moved to the backend:
>
> https://github.com/dlang/dmd/pull/14194

Awesome.
August 06

On Saturday, 6 August 2022 at 04:33:41 UTC, rempas wrote:

>

a new ecosystem where everyone will compile everything from
source with the many benefits this adds!

So a Gentoo? Now since Gentoo has been mentioned some one is required to mention Arch in the responses.

The only benefit I would want from compiling everything myself instead of downloading precompiled binaries is that I could enable specific optimizations for my system. The only backends that have all those optimizations are GCC and LLVM. What other benefits do you see that are worth the hassle?

I think when talking about creating executables from source code its better to use the word build instead of compiling to describe that process. In order to build the program you need to compile and link. The last time I built debug version of DMD on my system around half of the time was spent linking so even if you can get a significantly faster backend the whole build time wont change significantly. You need to think about the whole pipeline if you want big changes.

August 06

On Saturday, 6 August 2022 at 19:35:16 UTC, welkam wrote:

>

So a Gentoo? Now since Gentoo has been mentioned some one is required to mention Arch in the responses.

The only benefit I would want from compiling everything myself instead of downloading precompiled binaries is that I could enable specific optimizations for my system. The only backends that have all those optimizations are GCC and LLVM. What other benefits do you see that are worth the hassle?

Having the ability to create custom builds! Most of the times, this
is not a problem but there may be a chance where you have to build
your own version of a package (because you need the 'X' feature) and
the build-in package manager may not have greatest support to work
with its packages and your local ones. Another one, cross-compatibility!
No more wasting time for platform-specific bugs because this distro has
this built-in and that distro has this option enabled yada yada yada.
One package manager, all the systems! And as everything and everyone
builds from source, we can have one cross-compiler and we can build
a local version of the program. No more, "upload your binary" which,
yes it happened to me (if tho we did find the solution without having
to do that but still....).

>

I think when talking about creating executables from source code its better to use the word build instead of compiling to describe that process. In order to build the program you need to compile and link. The last time I built debug version of DMD on my system around half of the time was spent linking so even if you can get a significantly faster backend the whole build time wont change significantly. You need to think about the whole pipeline if you want big changes.

That's fair but linkers have become faster and faster! See lld for example!
In my experience, most of the projects (at least the C ones as this is where
we have tons of huge projects to test) spend around 90% of the whole
compiling process in compiling when using "lld" as the linker (and not link-time
optimization). I've seen C++ projects been different as C++ probably outputs more
complex symbols so the linker has to do more work and I don't remember for D (Even
tho I'm mostly sure that it falls in the C category where link times are faster). So
in the end, I think that improving the compile time (output object files) do matter.
Also, there is always the ability to create the final executable at one shot! This can
be extremely useful in release builds when you don't care about the object files anyways.
Is there any D backend that has been build to do that? Actually, the only compilers that
I personally know to do that are Vox and Vlang when using its "native" backend.

August 07
On 8/6/2022 11:02 AM, welkam wrote:
> On Saturday, 6 August 2022 at 07:39:36 UTC, Walter Bright wrote:
>>
>> The dmd backend is already in D :-)
>>
>> But since it's all Boost Licensed, anyone can use 0..100% of it for their own backend project. No asking is required.
>>
>> Have fun!
> 
> But where is inliner located?

DMD has two inliners, a front end one and a back end one. Here's the back end one:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/inliner.d


> I read that several other languages (Jai, Zig) are trying to make their own x86_64 backends because GCC and LLVM are too slow. If DMD backend had its IR well documented and inliner implemented not in the frontend I could see a future where it could be used by other languages.

The IR is very simple:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/backend/el.d#L70

It's a binary tree. Not clever at all. It's about 50 lines of declaration.

Too see it in action, use the --b --f switches:

    ./dmd test.d -c --b --f

which will pretty print the IR before and after optimization. There are some other switches, like --r which will show the register allocator at work.
1 2
Next ›   Last »