[Codegen][GPU]Fixing barrier placement for 3+ stages pipelining - #22725

…-org#22725)

In this PR, I created a new function insertBarriersInRange() that
enforces shared-memory ordering by tracking two flags
(needBarrierBeforeRead, needBarrierBeforeWrite) as it scans a block.
This replaces the old barrier insertion routine as more shared
read/write can be pushed to prologue and epilogue with 3+ stages of
pipelining.

Detailed description (copied from comments): 

Inserts synchronization barriers before shared memory accesses in the
given range using a running `SharedBarrierState`. Conceptually, we track
whether the next shared read (or write) must be preceded by a barrier,
and only emit one when that flag is set. For example,
1) if the iteration sequence observes a shared read (R) followed by
another read, nothing is inserted; the state only toggles
`needBarrierBeforeWrite`, so the next shared write (W) will emit a
barrier before it.
2) if the iteration sequence observes a shared write first toggles
`needBarrierBeforeRead`, so the following read receives the barrier.
This keeps the minimum number of synchronizations while still enforcing
the R↔W ordering required by the pipelined schedule.

Notes that all existing unit tests already have good coverage of barrier
placement so this PR doesn't need one. The new functionalities will
later be covered when 3 stage pipeline is added.

Signed-off-by: jerryyin <zhuoryin@amd.com>

…-org#22725)

In this PR, I created a new function insertBarriersInRange() that
enforces shared-memory ordering by tracking two flags
(needBarrierBeforeRead, needBarrierBeforeWrite) as it scans a block.
This replaces the old barrier insertion routine as more shared
read/write can be pushed to prologue and epilogue with 3+ stages of
pipelining.

Detailed description (copied from comments): 

Inserts synchronization barriers before shared memory accesses in the
given range using a running `SharedBarrierState`. Conceptually, we track
whether the next shared read (or write) must be preceded by a barrier,
and only emit one when that flag is set. For example,
1) if the iteration sequence observes a shared read (R) followed by
another read, nothing is inserted; the state only toggles
`needBarrierBeforeWrite`, so the next shared write (W) will emit a
barrier before it.
2) if the iteration sequence observes a shared write first toggles
`needBarrierBeforeRead`, so the following read receives the barrier.
This keeps the minimum number of synchronizations while still enforcing
the R↔W ordering required by the pipelined schedule.

Notes that all existing unit tests already have good coverage of barrier
placement so this PR doesn't need one. The new functionalities will
later be covered when 3 stage pipeline is added.

Signed-off-by: jerryyin <zhuoryin@amd.com>