<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - vs-temp-array-mat3-index-col-rd test fails with SB" href="https://bugs.freedesktop.org/show_bug.cgi?id=71944#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - vs-temp-array-mat3-index-col-rd test fails with SB" href="https://bugs.freedesktop.org/show_bug.cgi?id=71944">bug 71944</a> from <a class="email" href="mailto:ptpzz@yandex.ru" title="Vadim Girlin <ptpzz@yandex.ru>"> Vadim Girlin</a> <pre>(In reply to <a href="show_bug.cgi?id=71944#c5">comment #5</a>) > I tried to look a little closer at the group of instructions where you > thought the problem was. But I can't really wrap my head around how the > scheduling works. Yes, sometimes it looks unnecessarily complicated to me, rewriting some parts of the scheduler and adding new features on top of existing code made it a bit messy. I planned to rewrite it completely to make it more clean and simple, but I suspect it won't happen in foreseeable future. > When is the data dependency checking done? Is it when one instruction is > added to a group or after the whole group is done or even later? I'm not sure about exact terminology and classification of dependencies, I said it's a data dependency but I guess problematic dependency in this case is actually called anti-dependency (write-after-read), and it's checked for the entire group in the post_scheduler::check_interferences ("interference" here means the case when two different values are allocated to the same register at some point - we should prevent it). The check is not performed per instruction because we want to take into account parallel execution and allow reading old value from GPR and writing new value to that GPR in the same group. This allows to process the groups like this: x: MOV R0.x, R0.y y: MOV R0.y, R0.x Per-instruction check would disallow any of these instructions that comes first because it has dependency with the other one that is not processed yet. The check uses register map (post_scheduler::regmap) where the mapping of GPR index/component to value is maintained. If at some point value V is stored in R0.x, then the map contains entry (R0.x => V) and we know that we can't put new value into R0.x until the entry for previous value in the map is removed. When we process first use of some value (scheduling is performed in the bottom-up order, so actually it's the last use in the program execution order), corresponding entry is added to regmap, when we process it's definition the entry is removed from the map so that new value can be placed into that register. As for the data dependencies (read-after-write), the way of releasing instructions for scheduling ensures they are not broken - before scheduling alu block (one or more consecutive alu clauses) we compute the number of uses of each value that is defined in that block, and instruction that defines the value is released for scheduling only after all uses are scheduled, so the write is always scheduled after all reads (before all reads in normal non-bottom-up order). In this particular case I think the check for anti-dependency doesn't work as expected because there are special cases - some values can be preallocated/pinned to registers before the scheduling, and probably some situations are handled incorrectly or not handled at all. There are special flags that are shown in the dumps (with sbdump option), e.g. "R23.x.6||<a href="mailto:FP@R1.x">FP@R1.x</a>" means that value R23.x.6 (ssa-value R23.x with version 6, name contains original register used in source bytecode) has some special flags printed as "||", "F" and "P", and is stored in R1.x. Indirectly addressed GPR arrays are also allocated before the post-scheduler, and it seems there is some conflict between these preallocated registers that post-scheduler doesn't take into account. Hope this helps, because I'm not sure when/if I'll be able to look into it myself. But I'll be glad to help as I can, so let me know if you have any other questions.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>