Reuse product

Ran across this optimization because of some issues I was having with rodinia, but it's a good optimization to have regardless.

Because SROA is so aggressive, it will break up any product that it finds and then reconstruct products when needed (for returns and function arguments), so along with outlining, a program like

#[entry]
fn test(x: (i32, i32)) -> (i32, i32) {
  return x;
}

will end up with a host function that reads both fields from x and then writes them into a new product which it passes to the device function which reads both fields from x and then writes them into a new product which it returns, the host function then reads both fields of the returned value and writes them into a new product which it returns.

This optimization eliminates situations like this by identifying when two nodes are the same product and replaces the node which was constructed (by a series of writes) with the source one (this is always a constant, argument, or call node). This is an important optimization since otherwise we are performing copies of products which can be expensive (especially if they contain arrays).

I've run into a mix of GCM and RT code gen issues with code not optimized by this. The RT code gen I suspect is just from it not handling everything it would need yet to generate the code. The GCM issues I think have to do with collections that live entirely in the rust async (since they're being constructed there) and something in GCM failing because of that.

hercules_opt/src/lib.rs

@@ -18,6 +18,7 @@ pub mod lift_dc_math;
 pub mod outline;
 pub mod phi_elim;
 pub mod pred;
+pub mod reuse_products;
 pub mod schedule;
 pub mod simplify_cfg;
 pub mod slf;
@@ -43,6 +44,7 @@ pub use crate::lift_dc_math::*;
 pub use crate::outline::*;
 pub use crate::phi_elim::*;
 pub use crate::pred::*;
+pub use crate::reuse_products::*;
 pub use crate::schedule::*;
 pub use crate::simplify_cfg::*;
 pub use crate::slf::*;