blockaddress(@function, %block) IR?

Tove via digitalmars-d-ldc digitalmars-d-ldc at
Sat Aug 16 19:30:32 PDT 2014

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
> 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

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,

More information about the digitalmars-d-ldc mailing list