On Monday, 24 May 2021 at 10:21:44 UTC, Walter Bright wrote:

It makes it clear what they are for, which makes this statement:

obsolete.

The majority of the API are values, but it still needs to be fed AST information in order to make informative decisions.

For instance, how else would we be able to infer isReturnOnStack without a TypeFunction? Even GDC needs the completed TypeFunction, as I generate a tree on-the-fly and pass that to GCC's back-end API to get said information.

Target's first goal of removing all global.params.isXXX fields was never going to be easy either. :-)

We need big changes.
We need todolist(order by important).
We need to split big files into directories.
Small refactoring is useless.
Big changes are necessary.
We separate the stable part from the unstable part of the big file.And divided into small files.
According to dependence, change from the most dependent.
Interfacs or func name need not to change.
It's just that the organization has to be changed.
Nobody reads thousands of lines functions.
No one reads >100kb coding files because they are too large.
We just split up large files, not modify the function implementation.
Because modifying the function implementation is most likely to make mistakes.

On Monday, 24 May 2021 at 10:34:35 UTC, Walter Bright wrote:

I seriously question the "Optimized for people who spend thousands of hours working on it" line, as I had a very intelligent person posted on slacks asking what does this function do, as there is no comments for said functions.

-Alex

On Monday, 24 May 2021 at 10:47:16 UTC, Johan Engelen wrote:

Thank you for bringing us back on topic. Yes, or at least have a map of what is considered stable and well encapsulated and what is considered unstable and likely to change.

I don't believe this is a matter for git rebasing tooling/understanding. I just don't want to build directly on top of something that looks like it is likely to change (from a software engineering point of view).

I consider every hour spent on rebasing, dealing with regressions etc to be losses, or more importantly "not fun". I only want to do "not fun" things if I can learn something from them.

D has to rely on hobbyists, so getting "not fun"/"no learning potential" out of the way is important.

That is a bit harsh, of course all code bases that have evolved over a long time are not nice, parts of LDC too.

Anyway, my main wish is just to be able to inject my own IR between the frontend and backend.

My feeling right now is that to do that I have to choose LDC and then heavily modify it. I sense that in the end I basically will end up with my own backend, something I don't want to maintain...

Think of it like LEGOs. The front end is a green brick and the back end a red brick. I want to insert a white brick between them. I don't want to modify the bricks more than "cleaning" the studs.

Another analogy, if the frontend is an engine, my IR is the transmission and the backend is the wheels, then I don't mind that the current engine is oily and grease, I leave that to other mechanics to clean up. Same with the wheels. I just want to be an expert on the transmission and evolve it from a manual transmission into a nice automatic transmission. Right now the engine is coupled directly to the wheels... which basically means being forced to drive in the same gear all the time.

I am less interested in getting my fingers greasy and am happy to leave that to others as long as I can focus on polishing the chrome on my transmission line...

(I belive many things could be done with an intermediary high level IR, such as ARC, stackless coroutines, heap optimizations... LLVM is too low level. AST is too cumbersome.)

On Monday, 24 May 2021 at 14:37:45 UTC, Ola Fosheim Grøstad wrote:

I think you will end up with your own compiler :)

On Monday, 24 May 2021 at 12:38:59 UTC, zjh wrote:

100 kb is let's say 2500 slocs (or rather 1500 from the D-Scanner pov), that's not too crazy. Many DMD source files are big because they contain a visitor.
visitors cant be split in several files. Often you only actually are interested by a single method of a visitor so the overhall size of a source does not matter.

Eventually what could be done for the biggest methods of visitors is to extract parts of the content to several non-nested free functions, so that no more low level implementation details, like control loops, are visible and instead you just see do_this; do_that; with just a few, nzzcessarily unavoidable, flow statements.

The problem is that extracting and splitting the content would be tedious because of the decade of more or less well organized patchwork added to fix the bugs.

PS: backticks are for inline code, sourround with pairs of stars or pairs of underscores.

On Monday, 24 May 2021 at 19:42:00 UTC, user1234 wrote:

Actually, the visitors have been slowly getting converted into nested functions and a switch table.

On Monday, 24 May 2021 at 10:47:16 UTC, Johan Engelen wrote:

[...]

Yes. It's easier to understand shallow trees with modest leaves than arbitrary graphs with 1000+ LOC "leaves". Getting there will take some work. Fortunately, it looks like much of that work can be done "bottom up" i.e. incrementally.

When simplifying code readability is a commonly applied metric. How long does it take for an intelligent but "outside" developer to understand the code? Another useful metric is the degree of dynamic dependence: could this code run in parallel? If not, why not?

Examining the ability to run in parallel can also be done "bottom up", and is at least as valuable for simplification/correctness as it is for parallel speedup potential. That said, a taskification that followed our, sometimes extreme, code expansion contours could yield speedups that coarser approaches to multi-threading do not. It could also bring vibe style sanity in place of manually managed asynchrony where the dependencies are carried in your head.

When looking to foster task independence, building around dependency graphs which are immutable/committed in the interior and expanding/mutating/synchronizing at the frontier, is one way to go. (__traits compiles is interesting in this context...) The SDC people will have other ideas/experience to share if taskification becomes a thing.

Finally, my thanks again to the current front end crew and the LDC/dcompute crew. The tool chain may not be perfect but, boy, it's way better than falling back to C++/CUDA.

On Monday, 24 May 2021 at 15:16:34 UTC, sighoya wrote:

I think we need to learn from Apple and Microsoft, they are doing well, not only because of resources, but because they let people be specialists on certain aspects of the compiler. D has people who has specialized on the GC and LLVM, but it isnt a deliberate strategy... Yet.

Building a racing car is not a one man project...