[Bug rtl-optimization/29583] New: reorg.c checks insns for delay slots in the wrong order sometimes

[Bug rtl-optimization/29583] New: reorg.c checks insns for delay slots in the wrong order sometimes

[ersmith at hfx dot eastlink dot ca]

fill_simple_delay_slots, in reorg.c, scans backwards for instructions to put in
delay slots. It fills the slots in reverse order, i.e. if it finds an
instruction A it first puts it in slot 1, if it finds a second one B then A is
bumped down to slot 2, and B in slot 1; etc. However, the check
eligible_for_delay is called with a slots_filled count, so insn A is checked
for slot 1 and insn B is checked for slot 2, even though they end up in slots
in the opposite order.

Solving this in a fully general fashion is probably a real pain, since when
we're picking an insn we don't know how many more will be placed in the list.
However, if the restrictions on delay slots are ordered so that any instruction
that can go in slot 1 can go in slot 2, but not vice-versa, then we can check
all of the new insns against slot 1, and then before inserting we can check
that the old slot 1 is eligible for slot 2, old slot 2 for slot 3, etc. I have
a patch that does this, and it solved the problem for the VLIW processor I was
working with.

Another possibility would simply be abort the whole backwards scan once a
single slot is filled, and continue with the other (forward) scans, which seem
to work correctly.

The epilogue delay slot code likely has a similar problem, but that calls a
processor specific hook anyway, so the problem can be dealt with there.


-- 
           Summary: reorg.c checks insns for delay slots in the wrong order
                    sometimes
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ersmith at hfx dot eastlink dot ca
  GCC host triplet: any
GCC target triplet: any processor with more than one delay slot, not all
                    identical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29583

[Bug rtl-optimization/29583] reorg.c checks insns for delay slots in the wrong order sometimes

[ersmith at hfx dot eastlink dot ca]

------- Comment #1 from ersmith at hfx dot eastlink dot ca  2006-10-24 16:30 -------
Created an attachment (id=12484)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12484&action=view)
proposed patch to fix delay slot scheduling problems

Here is my proposed patch. It checks the existing insns to make sure they can
go in the next delay slots before inserting the new one; it also makes sure the
new insn is checked against the correct slot. On processors where there are
insns that can go in delay slot 1 but not slot 0 the patch is suboptimal, since
everything gets tried against slot 0 first; OTOH the existing code is wrong, so
suboptimal is an improvement :-).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29583