blockaddress(@function, %block) IR?
Tove via digitalmars-d-ldc
digitalmars-d-ldc at puremagic.com
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 http://wiki.dlang.org/LDC_inline_IR.
> A separate LLVM function is generated for the inlineIR template.
> The label is outside this function.
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
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()
More information about the digitalmars-d-ldc