This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix twolf -funroll-loops -O3 miscompilation (a semi-latent web.c bug)


> Attached is a different fix. It splits DF_REF_IN_NOTE in two: One flag
> for each kind of note. This allows the dead note removal code to
> distinguish the source note for the EQ_USES.  I needed to remove one
> flag to keep the df_ref_flags 16-bit, but the DF_REF_SUBREG flag looks
> completely unnecessary to me, and only ira.c uses it, so it wasn't to
> hard to scavenge a single bit.

I'll defer this to Paolo.

> 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.

> 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?

> 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?

> 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.

> Finally, it makes sense to compute the NOTE problem for CSE.

Why?  It only uses REG_EQ* notes, 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.

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]