- 
                Notifications
    
You must be signed in to change notification settings  - Fork 1.5k
 
          Further refactor TrampolineCompiler for the wasm ABI
          #11939
        
          New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
  
    Further refactor TrampolineCompiler for the wasm ABI
  
  #11939
              Conversation
This is a follow-up to bytecodealliance#11932 where the `TrampolineCompiler` type is further specialized to just working with the wasm ABI instead of trying to multiplex two ABIs now that the array ABI is handled by calling the wasm ABI. This involved purging the `self.abi` field and updating all callers as appropriate. This then performed some small refactoring to use `TrampolineCompiler` for compiler intrinsics. Unsafe intrinsics also now have the same strategy of calling the wasm ABI trampoline when compiling for the array ABI. This should ensure that all entry trampolines are going through the same function.
        
          
                crates/wasmtime/src/compile.rs
              
                Outdated
          
        
      | // Skip inlining into array-abi functions which are entry | ||
| // trampolines into wasm. ABI-wise it's required that these have a | ||
| // single `try_call` into the module and it doesn't work if multiple | ||
| // get inlined or if the `try_call` goes away. Pevent all inlining | ||
| // to guarantee the structure of entry trampolines. | ||
| ( | ||
| FuncKey::ArrayToWasmTrampoline(..) | ||
| | FuncKey::ComponentTrampoline(Abi::Array, _) | ||
| | FuncKey::UnsafeIntrinsic(Abi::Array, _), | ||
| _, | ||
| ) => { | ||
| log::trace!(" --> not inlining: not inlining into array-abi caller"); | ||
| return false; | ||
| } | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @fitzgen on this. One reason is that cranelift inlining doesn't support get_exception_handler_address but even if it did we couldn't properly inline in entry trampolines because we wouldn't have the right handler recorded at all call points. To handle that I disabled inlining into these callers no matter what.
My thinking is that these aren't perf-sensitive and if they are we need to figure something else out other than inlining.
          Subscribe to Label Action
This issue or pull request has been labeled: "wasmtime:api", "winch"
 
      Thus the following users have been cc'd because of the following labels: 
 To subscribe or unsubscribe from this label, edit the   | 
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, and should make adding new trampolines easier to do correctly. Thanks for doing this!
Co-authored-by: Joel Dice <joel.dice@fermyon.com>
This is a follow-up to #11932 where the
TrampolineCompilertype is further specialized to just working with the wasm ABI instead of trying to multiplex two ABIs now that the array ABI is handled by calling the wasm ABI. This involved purging theself.abifield and updating all callers as appropriate.This then performed some small refactoring to use
TrampolineCompilerfor compiler intrinsics. Unsafe intrinsics also now have the same strategy of calling the wasm ABI trampoline when compiling for the array ABI. This should ensure that all entry trampolines are going through the same function.