On Sat, Dec 1, 2012 at 3:54 PM, Eric Botcazou wrote: >> The patch also includes all places I've found so far where the >> compiler could create self-referencing notes: >> >> 1. optabs.c: Not sure what it was trying to do, but now it just >> refuses to add a note if TARGET is mentioned in one of the source >> operands. > > OK.
Thanks. I'll commit this separately. >> 2. gcse.c: gcse_emit_move_after added notes, but none of them was very >> useful as far as I could tell, and almost all of them turned >> self-referencing after CPROP. So I propose we just never add notes in >> this case. > > gcse_emit_move_after also preserves existing notes. Are they problematic? Yes, they tend to be invalid after PRE because the registers used in the PRE'd expression usually are not live anymore (making the note invalid). Sometimes CPROP "re-validates" the notes, but it doesn't seem wise to me to rely on that. >> 3. cprop.c: It seems to me that the purpose here is to propagate >> constants. If a reg could not be propagated, then the REG_EQUAL note >> will not help much either. Propagating constants via REG_EQUAL notes >> still helps folding comparisons sometimes, so I'm proposing we only >> propagate those. As a bonus: less garbage RTL because a >> cprop_constant_p can be shared. > > That seems a bit radical to me, especially in try_replace_reg which is used > for copy propagation as well. In cprop_jump, why is attaching a note to the > jump problematic? Most of the time a note from copy-propagation was not valid because the copy-prop'd reg was not live at the point of the note. >> 4. fwprop.c: If the SET_DEST is a REG that is mentioned in the >> SET_SRC, don' create a note. This one I'm not very happy with, because >> it doesn't handle the case that the REG is somehow simplified out of >> the SET_SRC, but being smarter about this would only complicate >> things. I for one can't think of anything better for the moment, >> anyway. > > OK. I'll commit this along with the optabs.c part. >> Finally, it makes sense to compute the NOTE problem for CSE. > > Why? It only uses REG_EQ* notes, Not really. It uses single_set in a few places, including delete_trivially_dead_insns and cse_extended_basic_block. > so it seems like we're back to the earlier > trick of using df_note_add_problem to clean up pre-existing REG_EQ* notes. Again: Not really. I also bootstrapped&tested without the cse.c change. I plan (and promise ;-) to add a REG_EQ* note verifier for GCC 4.9. Ciao! Steven
