https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> --- It can certainly get "unduly weird". Basically such instructions get put at the end of the ready queue as soon as its input dependencies are satisfied. If there's only a few such instructions, then the resultant schedule will be reasonably sane. But if all or most don't have a mapping to reservations, then the result can be totally insane and worse than not scheduling at all. I saw a case internally where a bunch of loads were ready to issue at the start of a loop. So those all go onto the ready list and get pulled off one by one in the same order in which they were added to the ready list. As the loads issue, dependent instructions get put on the tail of the ready list and would issue after *all* the originally ready loads issued. The result was the loop had its loads bunched up at the top and the multi-cycle computation instructions at the bottom. We'd have been better off not scheduling it at all as the original order interleaved the loads and computation. This all occurred because we didn't have any reservations defined for our chip -- so everything was "nothing".
