https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Richard Biener from comment #6) > (In reply to Jakub Jelinek from comment #0) > > ... but then > > comes dom2 and happily replaces > > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > > return _1; > > with > > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > > return Inf; > > (I think this is still correct) > > Note this is also a pessimization code-generation wise since if we > preserve the multiplication the result is readily available in a > register but as optimized we have another constant pool entry and load. > > So we might want to consider not propagating constants generated by > operations > we cannot eliminate. If the only consumer is a compare-and-branch we > can of course still end up with a seemingly dead stmt, so this would be only > for the missed optimization. Up to y'all if this is the way to go, but here are some thoughts... Off the top of my head, we have VRP and DOM propagating constants. Technically also simplify_using_ranges, but it's only called from VRP/DOM, and it currently only works with integers, so we should be ok here. I think we could limit propagation in may_propagate_copy() which both VRP and DOM gate on. VRP uses it through its use of substitute_and_fold_engine and DOM uses it directly. Would this work? Would we need to pass an additional argument to may_propagate_copy() (edge or statement) or can we determine validity by only looking at: bool may_propagate_copy (tree dest, tree orig, bool dest_not_phi_arg_p)
