Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Correctly perform side effects for "/" and "mod" (PR#7533) #1173
There is a difference between the two
P.S.: I just looked at cmmgen, it seems that
I think it's worth considering improvements in this area, but we should do the most straightforward fix first, especially given the history of bugs in this area.
@lpw25 and I were discussing trying to force these terms into a normal form (as Flambda does) so that this sort of problem doesn't arise. One way might be to partition side-effecting and non-side-effecting terms; then I think the kind of separation of "bind" functions that you propose would fall out naturally.
added a commit
this pull request
May 15, 2017
I had a further look at cmmgen. There are some opportunities for doing the refinement I suggested in
There is code to analyse purity of expressions in two parts of the backend:
I have the impression that the effect analysis loses precision as the program representation becomes more low-level: Clambda primitives that are known to be pure (or "generative", so erasable) become translated in ways that are harder to prove pure (instruction selection has architecture-specific parts to reason about which primitives get turned into assembly instead of a C call on which precision is lost). This suggests that, for the purpose of this question (can the evaluation of an unused expression be erased without changing the program semantics?), relying on Clambda-level information is better than relying on Cmm-level information (which is hard to flow from Selection to Cmmgen anyway).
I think that if we wanted to do this, one could consider changing the
The main question, of course, is whether this would actually matter on real-world code.
Just for fun, I implemented the