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