[INCOMPLETE] [GC] Support wrapping vararg functions in statepoint

Project Infrastructure LLVM Dev List Archives
1

I actually need this feature quite badly in my untyped language
compiler: since I support first-class functions, I've made the types of
all functions a standard vararg (so I can box them).

The implementation crashes when I try to read out the value of
gc.result. Hints as to what might be wrong?

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>

2

Your verifier changes look reasonable. The other changes look questionable though. Non gc.statepoint calls to var arg functions *definitely* work. Any change outside of statepoint lowering is highly suspect.

I'm pretty sure that calling a vararg function through a statepoint already works without code change (other than the verifier). (Or at least simple cases work.) Figuring out which work and which don't would give some insight.

Philip

3

Philip Reames wrote:

Any change outside of statepoint lowering is highly suspect.

Notice that SelectionDAGBuilder::LowerCallTo (the one I'm modifying)
has exactly one other caller: visitCall, which doesn't match vararg
functions. Every other codepath directly calls
TargetLowering::LowerCallTo, supplying CallLoweringInfo information
explicity (it's a structure with a vararg field).

I suspect I'm not overloading SelectionDAGBuilder enough.

I'm pretty sure that calling a vararg function through a statepoint already
works without code change (other than the verifier). (Or at least simple
cases work.) Figuring out which work and which don't would give some
insight.

AFAICT, extracting the result from a statepoint wrapping a vararg
function is the problem. If it's a void function, there's no problem.

4

Philip Reames wrote:

Any change outside of statepoint lowering is highly suspect.

Notice that SelectionDAGBuilder::LowerCallTo (the one I'm modifying)
has exactly one other caller: visitCall, which doesn't match vararg
functions. Every other codepath directly calls
TargetLowering::LowerCallTo, supplying CallLoweringInfo information
explicity (it's a structure with a vararg field).

I think I'm missing something here. What leads you to believe that visitCall doesn't handle vararg functions?

Also, I see calls in both visitInvoke and visitCall. I would assume these are the primary entry points...

I suspect I'm not overloading SelectionDAGBuilder enough.

I'm pretty sure that calling a vararg function through a statepoint already
works without code change (other than the verifier). (Or at least simple
cases work.) Figuring out which work and which don't would give some
insight.

AFAICT, extracting the result from a statepoint wrapping a vararg
function is the problem. If it's a void function, there's no problem.

Ah! That helps to understand the problem.

Can you separate out a change to the verifier which accepts void returning varargs and post that for review? I can sign off quickly.

5

Philip Reames wrote:

Can you separate out a change to the verifier which accepts void returning
varargs and post that for review?

Please double-check that it works on your end.

6

Philip Reames wrote:

I think I'm missing something here. What leads you to believe that
visitCall doesn't handle vararg functions?

Also, I see calls in both visitInvoke and visitCall. I would assume these
are the primary entry points...

I'm probably more confused about this than you are.

The callchain is approximately SelectionDAGBuilder::LowerCallTo ->
SelectionDAGBuilder::lowerInvokable -> TargetLowering::LowerCallTo ->
X86TargetLowering::LowerCall. Now, the isVarArg information needs to
be conveyed to LowerCall, and that happens via CLI.IsVarArg, which
TargetLowering::LowerCallTo accepts as a parameter.
SelectionDAGBuilder::LowerCallTo isn't passed that information, and
doesn't compute it to send to lowerInvokable (which builds the CLI for
TargetLowering::LowerCallTo).

How could SelectionDAGBuilder::LowerCallTo possibly handle vararg?

7

Step 1 - you should write a test case and check

However, I'd expect - which may be completely wrong! - that the 'vararg ness' of the call is either a property of the actually callee, the callsite, or both. Given we do pass the callee into CLI, it *might* happen that way. In fact, looking at CLI::setCallee, this is exactly what I see. http://llvm.org/docs/doxygen/html/TargetLowering_8h_source.html#l02347

Philip