llvm dev - Aug 2011 - [LLVMdev] LLVM backend: Treat some function calls specially

Hello,

I am writing an LLVM backend that generates byte code for a custom virtual
machine. Standard function calls are lowered to a simple
   CALL $offsetInByteCode
This works fine so far using the standard machinery of LLVM. But some
functions are not implemented in byte code, but delegated to native
implementations within the VM. Calls to these functions use a non-standard
calling convention and should be lowered to another opcode:
   CALL_NATIVE $functionIndex
where $functionIndex is a magic byte telling the VM which native function
should be called. As the set of native functions and function indices will
be extended over time, it should not be hardcoded into the backend but
given as input at compile time.


I have some vague ideas on how I could implement this, but would like to
ask for your ideas in order to keep me from going too far in a
wrong/cumbersome direction.


The first option that came into my mind is adding a new intrinsic
"llvm.myVM.call_native(i32 %funcIdx, ...)" and then linking at compile
time a module that looks like
   define void @foo(i32 %a) {
      call @llvm.myVM.call_native(i32 1, i32 %a)
   }
   define void @bar(i32 %a, i32 %b) {
      call @llvm.myVM.call_native(i32 2, i32 %a, i32 %b)
   }
   ...
But here I am unsure how to handle the return type of this intrinsic (can
it be overloaded to accept any return type?) and whether I can reuse the
TargetLowering::LowerCall and CCState::AnalyzeFormalArguments stuff.



Maybe another option is to add some kind of metadata to these function
declarations and then check in "LowerCall" whether these metadata
flags
are present. If so, then extract the funcIdx from metadata and lower this
call in a special way. If this is doable, are there some example of how I
can do that (or similar things)?


Maybe, you have an even better idea?


Many thanks in advance,
Jonas

Jonas,
 Why not lower everything to a single call during instruction selection, and
then write a machine function pass that translates the normal CALL's into
CALL_NATIVE?

Micah
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Jonas Gefele
> Sent: Thursday, August 04, 2011 9:56 AM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] LLVM backend: Treat some function calls specially
> 
> Hello,
> 
> I am writing an LLVM backend that generates byte code for a custom
> virtual
> machine. Standard function calls are lowered to a simple
>    CALL $offsetInByteCode
> This works fine so far using the standard machinery of LLVM. But some
> functions are not implemented in byte code, but delegated to native
> implementations within the VM. Calls to these functions use a non-
> standard
> calling convention and should be lowered to another opcode:
>    CALL_NATIVE $functionIndex
> where $functionIndex is a magic byte telling the VM which native
> function
> should be called. As the set of native functions and function indices
> will
> be extended over time, it should not be hardcoded into the backend but
> given as input at compile time.
> 
> 
> I have some vague ideas on how I could implement this, but would like
> to
> ask for your ideas in order to keep me from going too far in a
> wrong/cumbersome direction.
> 
> 
> The first option that came into my mind is adding a new intrinsic
> "llvm.myVM.call_native(i32 %funcIdx, ...)" and then linking at
compile
> time a module that looks like
>    define void @foo(i32 %a) {
>       call @llvm.myVM.call_native(i32 1, i32 %a)
>    }
>    define void @bar(i32 %a, i32 %b) {
>       call @llvm.myVM.call_native(i32 2, i32 %a, i32 %b)
>    }
>    ...
> But here I am unsure how to handle the return type of this intrinsic
> (can
> it be overloaded to accept any return type?) and whether I can reuse
> the
> TargetLowering::LowerCall and CCState::AnalyzeFormalArguments stuff.
> 
> 
> 
> Maybe another option is to add some kind of metadata to these function
> declarations and then check in "LowerCall" whether these metadata
flags
> are present. If so, then extract the funcIdx from metadata and lower
> this
> call in a special way. If this is doable, are there some example of how
> I
> can do that (or similar things)?
> 
> 
> Maybe, you have an even better idea?
> 
> 
> Many thanks in advance,
> Jonas
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi Micah,

the problem is that calling conventions differ ("i32 and i64 mixed"
versus "everything promoted to i64")
and I don't want to manually fix type promotion in a machine function pass,
when I get can this for free
in "LowerCall". Indeed, I can lower already some (small hard coded set
of) native functions in "LowerCall".

All that's missing is a mechanism to tag some functions as native (and pass
the function index) and
access this information during "LowerCall". By the way, this problem
of knowing which function is native,
would still be the same in a machine function pass, wouldn't it?

Cheers,
Jonas


Am 04.08.2011 um 19:06 schrieb Villmow, Micah:
> Jonas,
> Why not lower everything to a single call during instruction selection, and
then write a machine function pass that translates the normal CALL's into
CALL_NATIVE?
> 
> Micah
> 
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
>> On Behalf Of Jonas Gefele
>> Sent: Thursday, August 04, 2011 9:56 AM
>> To: llvmdev at cs.uiuc.edu
>> Subject: [LLVMdev] LLVM backend: Treat some function calls specially
>> 
>> Hello,
>> 
>> I am writing an LLVM backend that generates byte code for a custom
>> virtual
>> machine. Standard function calls are lowered to a simple
>>   CALL $offsetInByteCode
>> This works fine so far using the standard machinery of LLVM. But some
>> functions are not implemented in byte code, but delegated to native
>> implementations within the VM. Calls to these functions use a non-
>> standard
>> calling convention and should be lowered to another opcode:
>>   CALL_NATIVE $functionIndex
>> where $functionIndex is a magic byte telling the VM which native
>> function
>> should be called. As the set of native functions and function indices
>> will
>> be extended over time, it should not be hardcoded into the backend but
>> given as input at compile time.
>> 
>> 
>> I have some vague ideas on how I could implement this, but would like
>> to
>> ask for your ideas in order to keep me from going too far in a
>> wrong/cumbersome direction.
>> 
>> 
>> The first option that came into my mind is adding a new intrinsic
>> "llvm.myVM.call_native(i32 %funcIdx, ...)" and then linking
at compile
>> time a module that looks like
>>   define void @foo(i32 %a) {
>>      call @llvm.myVM.call_native(i32 1, i32 %a)
>>   }
>>   define void @bar(i32 %a, i32 %b) {
>>      call @llvm.myVM.call_native(i32 2, i32 %a, i32 %b)
>>   }
>>   ...
>> But here I am unsure how to handle the return type of this intrinsic
>> (can
>> it be overloaded to accept any return type?) and whether I can reuse
>> the
>> TargetLowering::LowerCall and CCState::AnalyzeFormalArguments stuff.
>> 
>> 
>> 
>> Maybe another option is to add some kind of metadata to these function
>> declarations and then check in "LowerCall" whether these
metadata flags
>> are present. If so, then extract the funcIdx from metadata and lower
>> this
>> call in a special way. If this is doable, are there some example of how
>> I
>> can do that (or similar things)?
>> 
>> 
>> Maybe, you have an even better idea?
>> 
>> 
>> Many thanks in advance,
>> Jonas
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>