How can we make it easier to experiment with the compiler?

[Iain Buclaw]

On Monday, 24 May 2021 at 22:18:35 UTC, Walter Bright wrote:
> On 5/24/2021 3:51 AM, Iain Buclaw wrote:
>> For instance, how else would we be able to infer 
>> `isReturnOnStack` without a `TypeFunction`?
> Challenge accepted!
>
> Let's see. The only things the TypeFunction for are:
>
> 1. the return type
> 2. the function linkage
> 3. if the function returns a ref
>
> Pass those in instead, and the need for TypeFunction goes away.
>

I still see a Type though. :-)

On my side, in pseudo-code this would become:

```
   tree type = build_gcc_type (return_type);
   if (isref)
     type = build_reference_type (type);
   return targetm.calls.return_in_memory (type);
```

Or alternatively, I could just abandon all accuracy and go with:

```
   return (return_type.ty == Tstruct || return_type.ty == Tsarray) 
&& !isref;
```

Because I know that this function doesn't affect the code 
generator, though users won't be able to reliably do 
introspection.

>
> Notice how isReturnOnStack depends on several random global 
> variables like os, is64bit, and isPOSIX. They can be passed in 
> as arguments, too (or passed in as a const ref to a struct 
> containing those as members).
>

They have been moved to the internal state of Target, so no 
longer random globals.

Information such as the target OS or CPU should not be floating 
around the front-end.  It should all be constrained to either the 
dmd.target interface or dmd.backend, leaving the front-end to 
only handle matters relating to language semantics.

> isReturnOnStack() then becomes a pure function! (and safe, 
> nogc, nothrow, all that good stuff)
>
> Those initialize() functions go away, too.
>
> The beauty now becomes that we can (at last!) easily and 
> correctly write unittests for it. target.d now becomes 
> INDEPENDENT of the rest of the compiler.
>
> How sweet it will be!

I think target.d could instead benefit from breaking out into 
per-backend modules though, such as target_linux.d, 
target_freebsd.d, target_x86.d, target_x86_64.d, ... to separate 
out concerns of the OS with concerns of the CPU.  It would be 
something completely dmd-specific though, as I don't use/re-use 
any part of what's present in dmd's source tree around this 
module.