Skip to content
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

Wiring up new executable library ABI to LLVM codegen. #4791

Merged
merged 2 commits into from
Feb 11, 2021

Conversation

benvanik
Copy link
Collaborator

@benvanik benvanik commented Feb 9, 2021

This switches the runtime and generated code to using the new executable
library signature while still routing all the outputs through the flatbuffers.
Future changes will start generating the library metadata structures.

Progress on #3580.

@benvanik benvanik added compiler/dialects Relating to the IREE compiler dialects (flow, hal, vm) codegen/llvm LLVM code generation compiler backend hal/cpu Runtime Host/CPU-based HAL backend labels Feb 9, 2021
@google-cla google-cla bot added the cla: yes label Feb 9, 2021
@benvanik benvanik force-pushed the benvanik-llvm-abi-new branch 4 times, most recently from 3286bba to e11f8d1 Compare February 9, 2021 16:10
@benvanik benvanik marked this pull request as ready for review February 9, 2021 16:18
Base automatically changed from benvanik-llvm-abi to main February 11, 2021 00:21
// a useful failure though the HAL does not mandate that all overflows are
// caught and only that they are not harmful - clamping byte ranges and never
// returning a failure is sufficient.
typedef int (*iree_hal_executable_dispatch_v0_t)(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, I think will be very useful (in the future) having executable to return some kind of status e.g block of code that verifies the dynamic shapes at runtime.

const size_t* binding_lengths;

// Optional imported functions available for use within the executable.
const iree_hal_executable_import_table_v0_t* imports;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NEAT!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still needs to be defined/requires goo - but at least there's a placeholder I can point to when people ask where it would go :)

Using this for all executables will reduce the overhead in the common
case (statically/dynamically linked codegen) where we care about perf
and require minimal translation for the weirder cases (VMLA) where we
don't.
This switches the generated code to using the new executable library
signature while still routing all the outputs through the flatbuffers.

Progress on #3580.
@benvanik benvanik merged commit 249ffc5 into main Feb 11, 2021
@benvanik benvanik deleted the benvanik-llvm-abi-new branch February 11, 2021 02:18
This was referenced Feb 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
codegen/llvm LLVM code generation compiler backend compiler/dialects Relating to the IREE compiler dialects (flow, hal, vm) hal/cpu Runtime Host/CPU-based HAL backend
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants