On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov <ma...@kugelworks.com> wrote: > On 11/12/2013, at 5:17 am, Ramana Radhakrishnan <ramana....@googlemail.com> > wrote: > >> On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos <pma...@broadcom.com> wrote: >>> Hi, >>> >>> Near the start of schedule_block, find_modifiable_mems is called if >>> DONT_BREAK_DEPENDENCIES is not enabled for this scheduling pass. It seems >>> on c6x backend currently uses this. >>> However, it's quite strange that this is not a requirement for all backends >>> since find_modifiable_mems, moves all my dependencies in SD_LIST_HARD_BACK >>> to SD_LIST_SPEC_BACK even though I don't have DO_SPECULATION enabled. >>> >>> Since dependencies are accessed later on from try_ready (for example), I >>> would have thought that it would be always good not to call >>> find_modifiable_mems, given that it seems to 'literally' break >>> dependencies. >>> >>> Is the behaviour of find_modifiable_mems a bug or somehow expected? > > "Breaking" a dependency in scheduler involves modification of instructions > that would allow scheduler to move one instruction past the other. The most > common case of breaking a dependency is "r2 = r1 + 4; r3 = [r2];" which can > be transformed into "r3 = [r1 + 4]; r2 = r1 + 4;". Breaking a dependency is > not ignoring it, speculatively or otherwise; it is an equivalent code > transformation to allow scheduler more freedom to fill up CPU cycles.
Yes, but there are times when it does this a bit too aggressively and this looks like the cause for a performance regression that I'm investigating on ARM. I was looking for a way of preventing this transformation and there doesn't seem to be an easy one other than the obvious hack. Additionally there appears to be no way to control "flags" in a backend hook for sched-rgn for DONT_BREAK_DEPENDENCIES . Again if the DONT_BREAK_DEPENDENCIES is meant to be disabled with these flags, then it looks like we should allow for these to also be handled or describe TARGET_SCHED_SET_SCHED_FLAGS as only a hook valid with the selective scheduler. > >> >> >> It's funny how I've been trying to track down a glitch and ended up >> asking the same question today. Additionally if I use >> TARGET_SCHED_SET_SCHED_FLAGS on a port that doesn't use the selective >> scheduler, this does nothing. Does anyone know why is this the default >> for ports where we don't turn on selective scheduling and might need a >> hook to turn this off ? > > SCHED_FLAGS is used to enable or disable various parts of GCC scheduler. On > an architecture that supports speculative >scheduling with recovery (IA64) it > can turn this feature on or off. The documentation for various features of > sched-rgn, sched-ebb and sel-sched is not the best and one will likely get > weird artefacts by trying out non-default settings. Well, it appears as though TARGET_SCHED_SET_SCHED_FLAGS is only valid with the selective scheduler on as above and is a no-op as far as sched-rgn goes. This whole area could do with some improved documentation - I'll follow up with some patches to see if I can improve the situation. Thanks for your reply though. regards Ramana > > -- > Maxim Kuvyrkov > www.kugelworks.com > >
