On 25.05.2011 18:41, Bernd Schmidt wrote:

On 05/25/2011 08:21 AM, Andrey Belevantsev wrote:
Vlad, Bernd, I wonder if we can avoid having recog_memoized>=0 insns
that do not have proper DFA reservations (that is, they do not change
the DFA state).  I see that existing practice allows this as shown by
Bernd's patch to 48403, i.e. such insns do not count against
issue_rate.  I would be happy to fix sel-sched in the same way.
However, both sel-sched ICEs as shown by PRs 48143 and 49014 really
uncover the latent bugs in the backend.  So, is it possible to stop
having such insns if scheduling is desired, or otherwise distinguish the
insns that wrongly miss the proper DFA reservation?

Add a bool target podhook, targetm.sched.all_insns_have_reservations,
and add an assert in the scheduler if it is true.

I'm not sure what a good default value would be. Defining it to true
would almost certainly break a few ports initially (even assuming we
override it in sh where it's known not to be true), but I guess it such
an assertion failure would be useful information for the target maintainers.
I think the hook is a better idea than the attribute because nobody will care to mark all offending insns with an attribute. However, I must take a look to see how much work should be done for x86-64 to make the hook return true by default. I didn't get even past the very first libgcc build with this assert enabled.

Andrey


Or, if we want to enable extra checking on ports where not all insns
have a reservation, a new insn attribute ("has_reservation") could be
defined, defined to evaluate to true by default in genattrtab, and
(set_attr "has_reservation" "0") added in the machine descriptions where
necessary.


Bernd

Reply via email to