An LLVM bug that affect both LDC and SDC. Worth pushing for

[Iain Buclaw via Digitalmars-d]

On 18 June 2014 22:29, deadalnix via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Wednesday, 18 June 2014 at 21:22:44 UTC, Iain Buclaw via
>
> Digitalmars-d wrote:
>>
>> Likewise here.  But unless I'm missing something (I'm not sure what
>> magic happens with @allocate, for instance), I'm not sure how you
>> could expect the optimisation passes to squash closures together.
>>
>> Am I correct in that it's asking for:
>> ------
>> int *i = new int;
>> *i = 42;
>> return *i;
>>
>>
>> To be folded into:
>> ------
>> return 42;
>
>
> That is the final goal. A first goal should be:
>
>
> int *i = new int;
> *i = 42;
> return 42;
>
> That first step is supposed to be done by LLVM infra itself (and
> it does for such a simple example, but if you multiply the new,
> it gets confused). It is necessary because at this point, the
> language specific pass will be able to detect that nobody ever
> read from the allocated memory and that it doesn't escape, so it
> can be optimized away.
>
> If the first step do not happen, then the second step won't
> either, and it cascade down to pretty stupid code generation.

I just tried out doing something simple in gdc to see if I could
trigger this - got optimisation passes to compile it down to:

_d_allocmemory (16);
_d_allocmemory (16);
return 36;

Which is more than what I expected... it managed to const-fold all
operations into a single return, just haven't lost the (now) useless
GC allocations for the closures that were removed as dead code.