[BACKEND] Optimize code generation for load with other arg

[ThomasRaoux]

When other is there we should use it to initalize the reg before doing the load instead of initializing the reg with 0.

Note that this does add a scoreboard dependency between the other def and the load but user can remove it by using a select if other comes from a high latency op.

[Jokeren]

Why it's a "scoreboard" dependency?

Note that this does add a scoreboard dependency between the other def and the load

I think using NVIDIA's terminology, scoreboard dependency refers mostly to dependency caused by memory instructions. Do you mean other is created by another memory op?

[ThomasRaoux]

Why it's a "scoreboard" dependency?

Note that this does add a scoreboard dependency between the other def and the load

I think using NVIDIA's terminology, scoreboard dependency refers mostly to dependency caused by memory instructions. Do you mean other is created by another memory op?

I meant register scoreboard, which is HW will stall waiting for a register to be ready.

Before we had:

mov r, 0
(p) load r
(!p) mov r, other <- this move can potentially be schedule later

and now we have

mov r, other <- there will be a wait for other reg here
(p) load r

[Jokeren]

mov r, other <- there will be a wait for other reg here
(p) load r

So this pattern has the benefit of releasing the other register earlier before the following load is finished?

[Jokeren]

user can remove it by using a select

What does "select" mean here? Do you mean tl.where?

[ThomasRaoux]

mov r, other <- there will be a wait for other reg here
(p) load r

So this pattern has the benefit of releasing the other register earlier before the following load is finished?

Yes it makes the liverange smaller, the flipside is that it removes scheduling opportunities.

user can remove it by using a select

What does "select" mean here? Do you mean tl.where?

Yes I mean tl.where. (I guess select would be the llvm IR inst generated)