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

David Nadlinger via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 18 15:33:01 PDT 2014


On Wednesday, 18 June 2014 at 21:14:48 UTC, Iain Buclaw via 
Digitalmars-d wrote:
> On 18 June 2014 14:18, David Nadlinger via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On Wednesday, 18 June 2014 at 09:29:14 UTC, Iain Buclaw via 
>> Digitalmars-d
>> wrote:
>>> IMO, the closure/frame generation should occur *after* 
>>> inlining.
>>
>>
>> How would that work if your inliner operates on some 
>> language-independent
>> IR?
>>
>
> I don't know LLVM to comment.  But the way GCC operates at a 
> higher
> level so that all information is available to use (the inlined
> function is just duplicated with all its parameters remapped 
> into
> variables, and the return expression is turned into an 
> assignment to a
> dedicated return-value variable).

You stated that closure/frame generation should occur after 
inlining. I doubt that this is feasible to implement in the 
current LDC architecture, and probably also in GDC (although I 
don't know its internals well enough to be sure).

What we do in LDC, by the way, is just to optimize the closure GC 
allocations into a stack allocation if we can prove the context 
is not escaped after inlining. This happens in a custom 
optimization pass on the IR level. deadalnix is presumably 
talking about something very similar he is working on for SDC.

David


More information about the Digitalmars-d mailing list