Describe instructions with same reg in def and use or mutiple defs and attach write latency

[Reshabh K Sharma]

On Fri, Jan 28, 2022 at 10:23 AM Segher Boessenkool <
segher@kernel.crashing.org> 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