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]

[patch] RFA: more fixes for PR55006


On Thu, Nov 29, 2012 at 12:53 AM, Steven Bosscher wrote:
> 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.
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> Finally, it makes sense to compute the NOTE problem for CSE.
>
> Bootstrap&testing in progress at the older revision I've been using to
> debug the darwin10 and sparc bugs. I'll test trunk head on x86_64 and
> powerpc later. In the mean time, let me hear what you think of this
> one :-)

So I've tested this patch:

Bootstrapped&tested on x86_64-unknown-linux-gnu at r193394.
Bootstrapped&tested on x86_64-unknown-linux-gnu at r193924.
Bootstrapped&tested on powerpc64-unknown-linux-gnu at r193924.

Of course, I also verified that the darwin10 and sparc issues that
spawned this long thread are fixed.

OK for trunk?

Ciao!
Steven

Attachment: PR55006_2.diff
Description: Binary data


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