On 09/19/2012 01:00 PM, Aurelien Jarno wrote: > The copy propagation doesn't check the types of the temps during copy > propagation. However TCG is using the mov_i32 for the i64 to i32 > conversion and thus the two are not equivalent. > > With this patch tcg_opt_gen_mov() doesn't consider two temps with > different types as copies anymore. > > So far it seems the optimization was not aggressive enough to trigger > this bug, but it will be triggered later in this series once the copy > propagation is improved.
Exactly where/how does this manifest as problematic? We do this mov_i32 trick from i64->i32 when we're truncating. Given that we're not (yet) targeting mips64 and having to maintain 32-bit sign-extended quantities, I can't see how that would matter. We do the i32->i64 trick immediately before a proper extension. In either case I can't see how plain copy propagation should matter until some other operation is involved. So, do we have some other data propagation bug that is being masked here? r~
