https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #13 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #12) > new_ready just adds insns to the ready list. High latency isn't > directly a problem: if we can schedule a high latency insn early > speculatively, that is a _good_ thing! Only if you're certain to need the result. If you aren't then you're blocking resources that might be used for other instructions to no useful purpose. Indeed, you might find that a tight loop now takes much longer because the speculative insn is never used but now dominates the critical path. If you're not certain to want the result you're probably better off letting the hardware speculation do the work, it will probably know how to abandon high latency operations if the path turns out to be false.
