[LLVMdev] Hash Table Virtual Calls with Conflict Resolution Stubs

[Sanjoy Das]

> For the former, two vague ideas I had were adding a new calling
> convention (it might be useful if external projects could use hooks to
> add in their own calling conventions) or modifying inreg to allow
> specifying a particular register (albeit encoding target-specific
> information like this isn't ideal).

Assuming you have full control over your environment, I'd not start by
writing a new calling convention.  I'd just have:

  ...
  %dest = load_from_itable()
  call i32 %dest(i32 METHOD_ID, rest of the arguments ...)
  ...

and have the conflict resolution stub be:

  define i32 @conflict_redo(i32 %method_id, arg0, arg1, arg2) {
    dispatch based on %method_id
  }

with the normal x86 calling conventions.  Later, as an *optimization*
I'd consider a custom calling convention for the %method_id argument.
Not using %rax for %method_id frees it up for use as %dest, for instance,
so using %rdi for %method_id may not actually be a bad idea in
practice.

If you have to inter-operate with legacy code and are not flexible on
how %method_id is propagated (i.e. it _has_ to be in %eax) then a
custom calling convention that puts the first argument in %eax is
probably the best way to go.

> As for forwarding arguments, it seems like the combination of
> 'musttail' and varargs come close to satisfying this. The only issue
> is that it's not possible to forward a return value.

I'm not sure I understand what you mean by "forward a return value",
but running the following:

declare i32 @f(i32, i64)

define i32 @conflict_resolution_stub(i32 %t, i64 %arg0) {
  %v = musttail call i32 @f(i32 %t, i64 %arg0)
  ret i32 %v
}

through `llc -O3` gives (trimmed output):

_conflict_resolution_stub:              ## @conflict_resolution_stub
pushq %rax
popq %rax
jmp _f                      ## TAILCALL

I'm not sure what the pushq and popq %rax is here, looks like a
codegen glitch, but you do get the jmp _f as expected.

-- Sanjoy