On Saturday, 6 August 2022 at 08:04:37 UTC, rempas 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.

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

int i(){return 0;}

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!

On Saturday, 6 August 2022 at 04:33:41 UTC, rempas 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?

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.

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

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....).

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.