Potential bug in MuIRBuilder.new_exp_func()
Description
It seems that the function id required in new_exp_func()
must be defined first before calling it. This is a bit counter-intuitive to the gen_sym()
first and resolve symbol later API design philosophy we are doing.
Code & Error Message
def test_exposed_func():
from rpython.rlib.rmu import holstein as rmu
mu = rmu.MuVM()
ctx = mu.new_context()
bldr = ctx.new_ir_builder()
"""
Builds the following bundle:
.typedef @i64 = int<64>
.const @c_1 <@i64> = 1
.const @c_0 <@i64> = 0
.funcsig @sig_i64_i64 = (@i64) -> (@i64)
.expose @inc_exposed = @inc <DEFAULT> @c_0
.funcdef @inc VERSION @inc.v1 <@sig_i64_i64> {
%blk0(<@i64> %n):
%n_suc = ADD <@i64> %n @c_1
RET (%n_suc)
}
:type rmu: rpython.rlib.rmu.holstein
:type bldr: rpython.rlib.rmu.holstein.MuIRBuilder
:return: None
"""
i64 = bldr.gen_sym('@i64'); bldr.new_type_int(i64, 64)
c_1 = bldr.gen_sym('@c_1'); bldr.new_const_int(c_1, i64, 1)
c_0 = bldr.gen_sym('@c_0'); bldr.new_const_int(c_0, i64, 0)
sig = bldr.gen_sym('@sig_i64_i64'); bldr.new_funcsig(sig, [i64], [i64])
inc = bldr.gen_sym('@inc'); # bldr.new_func(inc, sig) # having it here works
inc_exposed = bldr.gen_sym('@inc_exposed'); bldr.new_exp_func(inc_exposed, inc, rmu.MuCallConv.DEFAULT, c_0)
bldr.new_func(inc, sig) # having it here causes an error
inc_v1 = bldr.gen_sym('@inc.v1')
blk0 = bldr.gen_sym('@inc.blk0')
n = bldr.gen_sym('@inc.blk0.n')
n_suc = bldr.gen_sym('@inc.blk0.n_suc')
op_add = bldr.gen_sym(); bldr.new_binop(op_add, n_suc, rmu.MuBinOptr.ADD, i64, n, c_1)
op_ret = bldr.gen_sym(); bldr.new_ret(op_ret, [n_suc])
bldr.new_bb(blk0, [n], [i64], rmu.MU_NO_ID, [op_add, op_ret])
bldr.new_func_ver(inc_v1, inc, [blk0])
bldr.load()
Error message:
11:36:01.567 [main] ERROR uvm.refimpl.nat.NativeClientSupport$ - Error thrown in Mu while native is calling MuIRBuilder.load. This is fatal.
uvm.ir.irbuilder.UnknownIDException: MuID 65540 (name: @inc) is not defined. If your Mu IR bundle refers to previously loaded entities, make sure the IDs are correct. If it refers to entities in the current bundle, make sure they have the appropriate types. Also check if all instructions in a basic block are listed in the new_bb's arguments.
at uvm.ir.irbuilder.BundleConstructor$$anonfun$cascadeLookup$1$$anonfun$apply$4.apply(BundleConstructor.scala:35)
at uvm.ir.irbuilder.BundleConstructor$$anonfun$cascadeLookup$1$$anonfun$apply$4.apply(BundleConstructor.scala:33)
at scala.Option.getOrElse(Option.scala:121)
at uvm.ir.irbuilder.BundleConstructor$$anonfun$cascadeLookup$1.apply(BundleConstructor.scala:33)
at uvm.ir.irbuilder.BundleConstructor$$anonfun$cascadeLookup$1.apply(BundleConstructor.scala:33)
at scala.Option.getOrElse(Option.scala:121)
at uvm.ir.irbuilder.BundleConstructor.cascadeLookup(BundleConstructor.scala:32)
at uvm.ir.irbuilder.BundleConstructor.resFunc(BundleConstructor.scala:51)
at uvm.ir.irbuilder.BundleConstructor$$anonfun$uvm$ir$irbuilder$BundleConstructor$$_resFunc$1$1.apply(BundleConstructor.scala:78)
at uvm.ir.irbuilder.BundleConstructor$$anonfun$uvm$ir$irbuilder$BundleConstructor$$_resFunc$1$1.apply(BundleConstructor.scala:78)
at uvm.ir.irbuilder.BundleConstructor$$anonfun$makeBundle$5.apply(BundleConstructor.scala:185)
at uvm.ir.irbuilder.BundleConstructor$$anonfun$makeBundle$5.apply(BundleConstructor.scala:172)
at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
at uvm.ir.irbuilder.BundleConstructor.makeBundle(BundleConstructor.scala:172)
at uvm.ir.irbuilder.IRBuilder.makeBundle(IRBuilder.scala:79)
at uvm.ir.irbuilder.IRBuilder.load(IRBuilder.scala:83)
at uvm.refimpl.nat.CDefs$$anonfun$96.apply(cStubs.scala:1022)
at uvm.refimpl.nat.CDefs$$anonfun$96.apply(cStubs.scala:1019)
at uvm.refimpl.nat.SimpleClosure.invoke(cStubsHelperFunctions.scala:29)
at com.kenai.jffi.ClosurePool$Proxy.invoke(ClosurePool.java:334)