Support tail calls and bulk memory, optional function reordering pass - #6
Support tail calls and bulk memory, optional function reordering pass#6gkgoat1 wants to merge 16 commits into
Conversation
|
Thanks for this PR, @gkgoat1! I'm currently on parental leave and not writing or reviewing code, but I will take a look at this when I am back in mid-February. |
| Return { | ||
| values: &'a [Value], | ||
| }, | ||
| ReturnCall { |
There was a problem hiding this comment.
Can you add doc-comments to ReturnCall and ReturnCallIndirect variants here?
| type_index, | ||
| table_index, | ||
| } => { | ||
| // let sig = self.module.funcs[Func::new(*function_index as usize)].sig(); |
There was a problem hiding this comment.
Can you remove the commented-out line here?
| t | ||
| ); | ||
| if self.reachable { | ||
| // let values = values.to_vec(); |
There was a problem hiding this comment.
Can you remove the commented-out line of code here?
| pub start_func: Option<Func>, | ||
| pub debug: Debug, | ||
| pub debug_map: DebugMap, | ||
| pub custom_sections: IndexMap<String,Vec<u8>> |
There was a problem hiding this comment.
Would you mind running cargo fmt on your changes? This appears not to be rustfmt'd...
| Terminator, ValueDef, | ||
| }; | ||
|
|
||
| pub fn reorder_funcs_in_body(b: &mut FunctionBody, f: &BTreeMap<Func, Func>) { |
There was a problem hiding this comment.
Could you describe the goal of this pass? To me it reads like a possibly useful utility, but not a core optimization pass that a general compiler backend would have -- would it perhaps work just as well to host it in your use-case directly?
| names.functions(&func_names); | ||
| into_mod.section(&names); | ||
| for (k, v) in module.custom_sections.iter() { | ||
| into_mod.section(&CustomSection { name: &k, data: &v }); |
There was a problem hiding this comment.
I definitely understand the usefulness of preserving custom sections, but my main concern here is that some custom sections will refer to code or other contents of the module that we will have modified (or completely regenerated), and will no longer be valid. For example, a debug (DWARF info) section will no longer have valid offsets, and will at least confuse, if not crash, a debugger that tries to use it in conjunction with our output.
Is there a particular kind of custom section you need to preserve? Perhaps we could have an allow-list of custom sections that remain valid and thus are preserved?
note: no fuzzing yet due to updates
Add PrintDecorator hooks for Waffle's IR
3 participants
These are some changes I find useful for WAFFLE