Open AverardoDiMugello opened 3 days ago
None of them write to RETURN
Probably always including return is just incorrect. I checked and the OCaml Jib->SSA implementation (which is considerably more tested and used) doesn't do this.
Here, while finding the Dominance frontiers. This one I don't have much information on yet. The affected functions are zAArch64_MaxTxSZ, zAArch64_BlockDescSupported, zgic_read_ram, zImpDefBool, zImpDefBits, and zImpDefInt. I may not get to look at this one in-depth for a little bit, because I don't intend to do code-generation for most of those functions in my initial use-cases for the tool I'm building.
I don't have any immediate ideas here. I do remember spending a week ages ago hunting for a subtle bug in the OCaml SSA implementation that turned out to be a mistake in 'Modern Compiler implementation in ML' book, which had an existing errata. I'm not sure I fixed this bug here, I should check that because this sounds similar.
The way Isla uses this SSA transform is as an optimization - and it always checks using symbolic execution that the re-written result is equivalent to the original code, and if it isn't the SSA form is just thrown away. That's essentially meant that bugs in this code haven't really mattered unless they affected a function I really wanted to apply this optimization too.
Thanks, this is helpful context. I can take a look at the OCaml Jib->SSA implementation and compare it with Isla.
I'm writing a compiler that translates Jib to LLVM, targeting the ARMv9.4a snapshot as my initial use case and consuming isla-lib as a dependency therein. The CFG::ssa function panics for several Jib functions from this snapshot in two separate places.
Here, in place_phi_functions, while iterating over each declared var's defsites. The bug is related to the RETURN builtin being included in the all_vars arguments of place_phi_functions, even though some functions don't ever write to it. This means that RETURN doesn't appear in the result of the CFG::nodewrite call and therefore doesn't get added to the defsites collection. We then panic when trying to unwrap the look-up for RETURN in defsites. The affected functions include zThrowSError, zReservedEncoding, and zEndOfInstruction. Each of these write to the exception-related builtins and use the Arbitrary terminator. None of them write to RETURN. Several system register access functions are affected too, specifically some, but not all, of the ICH, ICV_, ICC*, and AMEVCNTVOFF0* families of functions. My current bug-fix is to replace the offending unwrap with an if-let that does nothing if "a" doesn't have a defsite. I haven't tested the effects of this other than that the crashes have gone away. I'll post and link a pull request soon. I also notice that the exception-related builtins aren't included in all_vars like RETURN is. I'm not sure what the effects of this are.
Here, while finding the Dominance frontiers. This one I don't have much information on yet. The affected functions are zAArch64_MaxTxSZ, zAArch64_BlockDescSupported, zgic_read_ram, zImpDefBool, zImpDefBits, and zImpDefInt. I may not get to look at this one in-depth for a little bit, because I don't intend to do code-generation for most of those functions in my initial use-cases for the tool I'm building.
Here is some minimal code to reproduce the issue: