blockaddress(@function, %block) IR?

[Tove via digitalmars-d-ldc]

On Saturday, 16 August 2014 at 21:25:58 UTC, Kai Nacke wrote:
> Hi Tove!
>
> On Friday, 15 August 2014 at 18:10:45 UTC, Tove wrote:
>> I'm now convinced it's a bug, I get this error-message:
>
> Please read http://wiki.dlang.org/LDC_inline_IR.
>
> A separate LLVM function is generated for the inlineIR template.
> The label is outside this function.
>
> Regards,
> Kai

Hi Kai,

thanks for your help, actually that page was the very reason I
started using the inlineIR.

However the really exciting part of 'blockaddress' in LLVM is
that it supports accessing labels inside different functions,
this is why it takes 2 parameters!(I verified that accessing a
label inside another function works fine when manually writing
the IR)

If it had taken only 1 param I could have gotten it to work by
accessing a local label inside the IR.

But anyway, it is _NOT_ the label-lookup which fails, it is the
function-lookup!

In order to attempt to workaround, I tried to declare a function
prototype both in the IR and in D.
======================
Inserting "extern(C) byte* fun();" on line 1, didn't help.

Also using IR "declare" inside another nested function definition
seems illegal in LLVM, thus it's also not a feasible workaround.
======================

Because it's the function-lookup which fails, I started
suspecting that call would fail as well and actually it does,
although it gives me a different error message.
======================
use of undefined value '@fun'
======================                  ^
%tmp = call i8* @fun()
======================

Best Regards,
Tove