What should happen here?

[Steven Schveighoffer]

On 9/23/21 6:54 AM, Johan wrote:

> For the simple Pin version above, LDC generates the same machine code 
> with/without Pin (as expected):
> 
> https://d.godbolt.org/z/MW7d9Mefe

So that's not showing the issue (without the -version=PIN)

I couldn't get it to show on certain platforms, including ldc 64-bit. On 
32-bit it does fail, and the PIN fixes it.

HOWEVER, I have implemented a suggestion by Adam that perhaps the reason 
the first call to GC.collect doesn't cause a collection to occur is 
because the leftover stack might contain some reference, and it's not 
sufficiently clobbered. So adding:

```d
void foo()
{
    int[1000] x;
    writeln(x[1]);
}
```

And calling that function before calling GC.collect Seems to do the 
trick for 64 bit. Adding a new wrinkle here is that now BOTH versions 
collect early.

https://d.godbolt.org/z/rrnYPeYa3

And even dmd -inline -O is smart enough to see through this.

So I added the opaque function call, and even that wasn't enough (it 
didn't use any variables)

So I added passing the `t` through the opaque function, and this has 
fooled dmd, but not ldc (which I'm guessing is doing optimization on the 
mangled name, and so can see right through my opaque trick). Possibly, 
we could create a truly opaque library function. I also tried just 
putting an empty `asm` block inside.

But I can't be certain if it's working or not, the results are 
inconsistently showing both outputs.

I think we will need a real compiler intrinsic at this point.

-Steve