This is the mail archive of the gcc-bugs@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]

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


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


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