ir.InlineAsm does not implement value.Named

[driusan]

The documentation for NewCall says it may have one of the following types:

*ir.Function
*types.Param
*constant.ExprBitCast
*ir.InstBitCast
*ir.InstLoad
*ir.InlineAsm

However, ir.InlineAsm doesn't implement the value.Named interface, so trying to use it as the callee parameter results in a compile time error about *ir.InlineAsm not implementing GetName()

[mewmew]

@driusan good catch. The ir.NewCall function used value.Value as the type of the callee, while the ir.BasicBlock.NewCall method used value.Named as the type of the callee.

This has been fixed, and now both constructors use value.Value.

Cheers
/u

[pwaller]

I think this got broken again at some point? I get an error telling me that the .Type() of the InlineAsm I pass is not a FuncType.

llvm/ir/inst_other.go

Lines 344 to 355 in f20e2cd

	t, ok := inst.Callee.Type().(*types.PointerType)
	if !ok {
	panic(fmt.Errorf("invalid callee type; expected *types.PointerType, got %T", inst.Callee.Type()))
	}
	sig, ok := t.ElemType.(*types.FuncType)
	if !ok {
	panic(fmt.Errorf("invalid callee type; expected *types.FuncType, got %T", t.ElemType))
	}
	if sig.Variadic {
	inst.Typ = sig
	} else {
	inst.Typ = sig.RetType

[mewmew]

There are many special cases to consider in LLVM IR, I keep learning of new ones even after years of playing with these things. Thanks for re-opening the issue. It seem, the proper solution is to do a type switch and allow a function type directly (to cater for inline asm values).

[mewmew]

To be honest, another solution could be to have inline asm values have pointer to function type, instead of function type. How does the official LLVM distribution treat inline asm types? As func type or pointer to func type?

[mewmew]

A simple test program that should produce the return code 42.

package main

import (
	"fmt"

	"github.com/llir/llvm/ir"
	"github.com/llir/llvm/ir/constant"
	"github.com/llir/llvm/ir/types"
)

func main() {
	m := ir.NewModule()
	// inline asm
	funcType := types.NewFunc(types.I32, types.I32)
	asm := ir.NewInlineAsm(funcType, "add $1,$0", "=Q,Q,~{dirflag},~{fpsr},~{flags}")
	// main
	main := m.NewFunc("main", types.I32)
	entry := main.NewBlock("")
	result := entry.NewCall(asm, constant.NewInt(types.I32, 21))
	entry.NewRet(result)
	fmt.Println(m)
}

u@x1 ~/D/g/s/p/aa3> go run main.go > b.ll
u@x1 ~/D/g/s/p/aa3> lli b.ll ; echo $status
42

[pwaller]

Hmm, I'm uncertain whether my complaint was valid or not. Part of the issue was that I didn't understand how to use inline asm properly. With what you've written above and #74 I'm now happily able to use it. I don't have any strong feelings about how this should work.

[mewmew]

Before closing this issue, I still wish we could evaluate how the official LLVM distribution treats the type of inline asm, and then decide to be consistent with that.

This would follow the Principle of Least Surprise, for any user coming from official LLVM to llir/llvm.

@pwaller, do you have the LLVM C++ distribution installed, and if so, could you write a minimal test just to verify if inline asm has pointer to func type or func type?

[dannypsnl]

Do not have a computer to try now, but I guess https://stackoverflow.com/questions/29184031/how-to-get-llvm-inline-asm-operands-type would help?

[mewmew]

@dannypsnl, thanks!

From https://stackoverflow.com/questions/29184031/how-to-get-llvm-inline-asm-operands-type:

In LLVM, InlineAsm is a subclass of Value, and the associated value is always of type pointer-to-function.

So, we can close this issue. And let users create inline asm values with type pointer to function type.

[pwaller]

I added a bullet to the typechecking issue #65 - we should type-check the arg to NewInlineAsm. Also, it would seem reasonable to me for that function to accept either a types.Func or types.Pointer - in the former case simply wrapping the func with types.NewPointer.