http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
Jeffrey A. Law <law at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at redhat dot com --- Comment #7 from Jeffrey A. Law <law at redhat dot com> --- So I see a few issues here. First the copyprop pass does not discover new const/copies. So if we have _2 = 344; ubound.0_3 = _2 & 7; size.1_4 = ubound.0_3 + 1; size.1_5 = MAX_EXPR <size.1_4, 0>; _6 = size.1_5 * 4; _7 = (character(kind=4)) _6; _8 = MAX_EXPR <_7, 1>; sizes_9 = __builtin_malloc (_8); size.3_10 = MAX_EXPR <ubound.0_3, 0>; _11 = size.3_10 * 4; _12 = (character(kind=4)) _11; _13 = MAX_EXPR <_12, 1>; strides_14 = __builtin_malloc (_13); MEM[(integer(kind=4)[0:D.1917] *)sizes_9][0] = 1; if (ubound.0_3 > 0) goto <bb 3>; else goto <bb 6>; We discover _2 = 344 and copyprop that to its uses. However, copyprop does not discover that the RHS of ubound.0_3's assignment will simplify into a copy until *after* the main copy propagation algorithm is complete. ie, that isn't discovered until subsitute_and_fold. Basically anything that doesn't look like a const/copy initialization when the pass starts is effectively ignored. Durding substitute_and_fold, we substitute the value 344 for uses of _2. But we don't pick up that ubound.0_3 now has a propagatable value. Worse yet, because we walk backwards through the statements, even if we recorded that ubound.0_3 has a propagatable value we wouldn't be able to utilize that information. What a mess. My preference would be to enhance the copy propagation pass to discover these secondary copies. That would obviously slow down the pass as it's going to have to look at a lot more statements and there'll be more statements to reevaluate as values move through the lattice. Another possibility would be to do some kind of post-processing after substitute_and_fold to recognize that new const/copies were exposed and do something sensible.