Comparing changes

… code. (#73085) The problem occurs when an entire type/assembly is preserved through explicit rooting (command line, rd.xml, ...). If such type contains a local function (for example) which is only called from a branch which is going to be removed by constant-prop/branch removal the internal tracking of compiler generated methods will see this local function as orphaned (not belonging to any user method). This leads to a case where we will try to run data flow on the local function - but that should never happen for compiler generated methods directly -> assert. The fix is (just like in the linker), to never run data flow on compiler generated methods directly - they should only run data flow as part of their respective user method. Fixes #73027

* Add localloc empty stack verification * Update error message * Add more tests * Fix tests Co-authored-by: Jan Kotas <[email protected]> Co-authored-by: Dan Moseley <[email protected]>

* [mono][interp] Don't allocate some vars as execution stack It is not really true and it serves no purpose here. * [mono][interp] Print code before any optimizations take place Fix bitrotten mono_interp_print_td_code. Don't print IL_SEQ_POINT opcodes since they are too noisy. * [mono][interp] Use td->optimized directly in more places * [mono][interp] Add dummy MINT_LDNULL instruction We were pushing local that wasn't defined by any instruction, potentially confusing the var offset allocator. * [mono][interp] Add fast offset allocator, to be used by unoptimized code This is the old offset allocation scheme that we were using originally, before the var offset allocator was added. Vars have the same offset as they would have in IL code, based on their position on the execution stack at the moment when they are pushed. Whenever we push/pop on the execution stack we keep track of the used stack size. Every var pushed on the execution stack will therefore have this stack_offset remembered. Once the entire IL code is traversed and we have all the global locals allocated, the real offset of the execution stack locals can be determined. It is computed as the originally determined stack_offset added with the offset of the execution stack start (size of the global locals space). With this offset allocator, calls no longer need to store all the call args sregs and the return_offset is always the same as call_args_offset. This is because all vars are directly placed in the right position and no optimizations can move them around. The offset of the return value will therefore be also the offset where all the args are placed. The limitation with this way of allocating offsets is that we run into the same problems with opcodes that don't have typical stack usage (use values, pop them, store result). This happens with newobj opcodes. The opcode receives the params, and then it needs to call a ctor with these same params and a newly allocated this object. Since we can't use a var offset allocation pass to compute the offset ideally, the newobj opcodes in the case of unoptimized code must move these params around on the stack, in order to make room for `this`. * [mono][interp] Add dreg to all calls in unoptimized code All calls need to have a dreg (a dummy one if it is void call), in order for unoptimized offset allocator to determine the offset of the call. In unoptimized code, the offset of the first argument is always the same as the offset of the return, if any. * [mono][interp] Fix issue with passing of exvars Unoptimized code can't use a global local directly (like the exvar), it must first be pushed to a new var on the execution stack. Add a mov instruction when we start executing the basic block for a handler.

This adds several dataflow tests from linker - only those which are passing with the fixes in this change. More will be added later. Fixes: - Correctly handle Requires attributes in generic types - Recognize `ref Type` as interesting for data flow - Fix generic parameter propagation for compiler generated types - Treat multi-dimensional arrays as "Unknown" values (to match linker behavior) - Improve origin of warnings generated from attributes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Commits on Aug 1, 2022

This comparison is taking too long to generate.

Uh oh!