On 6/12/2013, at 9:44 pm, shmeel gutl <shmeelg...@shmuelhome.mine.nu> wrote:
> On 06-Dec-13 01:34 AM, Maxim Kuvyrkov wrote: >> On 6/12/2013, at 8:44 am, shmeel gutl <shmeelg...@shmuelhome.mine.nu> wrote: >> >>> On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote: >>>> Dependency type plays a role for estimating costs and latencies between >>>> instructions (which affects performance), but using wrong or imprecise >>>> dependency type does not affect correctness. >>> On multi-issue architectures it does make a difference. Anti dependence >>> permits the two instructions to be issued during the same cycle whereas >>> true dependency and output dependency would forbid this. >>> >>> Or am I misinterpreting your comment? >> On VLIW-flavoured machines without resource conflict checking -- "yes", it >> is critical not to use anti dependency where an output or true dependency >> exist. This is the case though, only because these machines do not follow >> sequential semantics for instruction execution (i.e., effects from previous >> instructions are not necessarily observed by subsequent instructions on the >> same/close cycles. >> >> On machines with internal resource conflict checking having a wrong type on >> the dependency should not cause wrong behavior, but "only" suboptimal >> performance. >> >> ... > Earlier in the thread you wrote >> Output dependency is the right type (write after write). Anti dependency is >> write after read, and true dependency is read after write. > Should the code be changed to accommodate vliw machines.. It has been there > since the module was originally checked into trunk. The usual solution for VLIW machines is to have assembler split VLIW bundles that have internal dependencies and execute them on different cycles. The idea is for compiler to strive to do its best to produce code without any internal dependencies, but it is up to assembler to do the final check and fix any occasional problems. [A good assembler has to do this work anyway to accommodate for mistakes in hand-written assembly.] The scheduler is expected to produces code with no internal dependencies for VLIW machines 99% of the time. This 99% effectiveness is good enough since scheduler is often not the last pass that touches code, and subsequent transformations can screw up VLIW bundles anyway. -- Maxim Kuvyrkov www.kugelworks.com
