SSA bugs :(

[b-paul]

prog entry @main;

proc @main() -> () [
  block %loop [
    // pretend this does stuff
    goto(%loop, %ret);
  ];
  block %ret [
    return();
  ];
];

crashes from a hashtbl find. Is it just the case that there should never be a block edge to the entry block?

and

proc @main(l:bv64) -> () [
  block %entry [
    goto(%loop, %ret);
  ];
  block %loop [
    (var l:bv64) := call @next(l:bv64);
    goto(%loop, %ret);
  ];
  block %ret [
    return();
  ];
];

proc @next(p:bv64) -> (next:bv64) [
  block %body [
    return(p);
  ];
];

mistranslates to

proc @main()  -> () {  }
[
   block %entry [ goto (%ret,%loop); ];
   block %loop [
     (var l_1:bv64=next) := call @next(p=l:bv64);
     goto (%ret,%loop);
   ];
   block %ret [ return; ]
];
proc @next(p:bv64)  -> (next:bv64) {  }
[ block %body [ var next:bv64 := p:bv64; return; ] ];
prog entry @main;

notice that l does not get a phi node coming from l_1...

[agle]

I think we generally assume input params are immutable which accounts for the second. Is this the "ssa" batch transform or just the ssa.

[b-paul]

this is the batch ssa transform

it would be helpful if such assumptions were documented somewhere or enforced with asserts because there's not any way to figure them out lol

[agle]

I should be checked in the wellformedness batch in checks.ml which is run before and after every transfrom. I was working on encoding constness systematically but it ended up being complex to get consistent constness of variable declarations and uses across a procedure in the frontend in the presence of loops and ssa/nonssa code. This led me to implementing HM type inference for a proper elaboration pass but first needed to refactor the expression ast so theres a sensible place to annotate types which i merged monday. So the constness checks arent there yet, we could specifically check for assignments to parameters though.