[PATCH] PR optimization/11741: PRE multiple sets in a PARALLEL

[Roger Sayle]

> In message <20030904210851.GB7100@redhat.com>, Richard Henderson writes:
>  >On Wed, Sep 03, 2003 at 09:57:15PM -0600, Roger Sayle wrote:
>  >> Before dropping this patch [which solves a PR, because there might
>  >> be a bug elsewhere in the compiler, which hasn't yet caused a PR]
>  >
>  >This is not the right way to think.  I know for a fact the patch
>  >will cause other problems; I havn't bothered to find a test case,
>  >but it would only be a matter of time.
> I agree with Richard here.  Failure to treat the parallel elements at
> a single unit is ultimately going to fail.

Let's just remind ourselves of the issue here.  I'm not trying to
introduce handling of multiple sets into GCSE.  Someone else has already
done that, and some other global write priviledge maintainer has already
approved it.  Indeed, cvs annotate seems to indicate that hash_scan_insn
was changed to call hash_scan_set on all the SETs in a PARALLEL by the
following patch:

Fri Feb 16 12:41:30 2001  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>

        * gcse.c (hash_scan_set): If cprop, see if REG_EQUAL or REG_EQUIV.
        Don't CSE a nop.
        (hash_scan_insn): Clean up calls to hash_scan_set.
        (compute_kill_rd): REGNO now unsigned.
        (try_replace_reg): Rework to use simplify_replace_rtx.
        (cprop_jump, cprop_cc0_jump): Likewise.
        (cprop_insn): Call find_reg_equal_equiv_note.
        Reflect changes to cprop_jump and cprop_cc0_jump.


So whatever you folks think this might break, has been broken since
atleast gcc 3.0.  I believe reverting this change to not handle the
sets in a PARALLEL would adversely affect performance.  For example,
a constant assigned anywhere in a parallel can usefully be propagated...

The issue now becomes how to avoid the abort in PR opt/11741!


> If you try to allow elements of a parallel to independently make later
> non-parallel expressions rundundant, then you open a rather nasty can
> of worms in terms of placement of the parallel to make all the later
> expressions fully redundant.

Indeed, you can't or wouldn't want to move/replace the entire parallel.
However, GCSE rarely "moves" instructions themselves, instead for the
"SET" of interest it calls emit_move_insn, to copy the SET_SRC to a
SET_DEST.  Indeed, any of the sets within a PARALLEL could be "moved"
in this fashion.  For "movsb", we could move the store to memory, or the
increment of %esi or the increment of %dsi, all of which are independently
recognizable instructions.


I don't doubt for a moment that there might be other bugs lurking in
GCSE's code.  But could someone please make a constructive suggestion
on how they think this problem should be resolved.  We could remove the
movsb pattern from i386.md, that would certainly fix it! :>

Roger
--