On Fri, Jan 28, 2022 at 10:23 AM Segher Boessenkool < segher@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jan 28, 2022 at 10:39:54AM -0700, Jeff Law via Gcc-help wrote: > > On 1/26/2022 6:20 PM, Reshabh K Sharma via Gcc-help wrote: > > >I am trying to implement a post address update load instruction in our > > >downstream riscv backend. I want to attach write latency information to > a > > >use register. For example, rd = new_load rs1 rs2, I want to attach > separate > > >write latency information to both rd and rs1. > > > > > >I am unable to find how to describe instructions that have an operand as > > >both def and use, and later attach write latency information for the > > >instruction scheduler to work properly. > > > > > >It will also be very helpful if you can point me to the implementation > of > > >similar instructions in other backends, for example, LBZU in PowerPC, > ARM's > > >LWD post/pre address update versions and ARM's neon simd load with > update. > > I'm not sure the scheduler can model different latencies for the > > multiple outputs. If anyone knows for sure, it would be Vlad. > > You can use TARGET_SCHED_ADJUST_COST? > Thank you so much! I think target_sched_adjust_cost will do. Given two rtx_insn, x = exp_load addr offset and y = add addr z, these two instructions are the input arguments to target_sched_adjust_cost, how do I check that given rtx_insn is exp_load? (how do we check if rtx_insn is of type exp_load, add or any other target specific instruction?) and how do I check if there is a read after read dependency for addr operand and not the offset. > It may not matter in practice though. I'd hazard a guess these things > > hang out in the reorder buffer until both outputs are ready and only > > then will it move into the retirement queue. > > The GCC scheduling description says when results are ready, not when the > instructions (can) finish or complete (aka retire). I do agree this > case doesn't matter so much, cases where it does matter will have their > dependency chains broken much earlier :-) > > > Segher Thanks again for the help! Reshabh
