Skip to content

PIX: Don't seek beyond terminator instructions (value-to-declare pass… #3856

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 30, 2021

Conversation

jeffnn
Copy link
Collaborator

@jeffnn jeffnn commented Jun 30, 2021

…) (#3855)

Background: this pass is trying to find all dbg.value and replace them with dbg.declare. In the code being changed, the pass is trying to seek a valid location at which to insert the dbg.declare. It has to come after the value to which it applies (which isn't true of the dbg.value). So there's this little loop trying to move forward to find the right instruction before which to insert new stuff.

I was expecting getNextNode to return null when there is no next node. When called on a terminator, it actually returns a non-null but malformed instruction pointer. So we have to explicitly check for terminators in this loop.

This really short basic block tripped up the pass:

; :274 ; preds = %.lr.ph55
%RawBufferLoad = call %dx.types.ResRet.i32 @dx.op.rawBufferLoad.i32(i32 139, %dx.types.Handle %lightBuffer_texture_structbuf, i32 %lightIndex.0, i32 28, i8 1, i32 4), !dbg !384
%275 = extractvalue %dx.types.ResRet.i32 %RawBufferLoad, 0, !dbg !384
switch i32 %275, label %288 [
i32 0, label %276
i32 1, label %280
i32 2, label %284
], !dbg !397
I think the pass could be smarter about seeking the right insertion point for the dbg.declare. It's currently assuming that the dbg.value always succeeds the value to which it refers, but as in this case, that's not always true. But that's a project for another day.

(cherry picked from commit 650de80)

microsoft#3855)

Background: this pass is trying to find all dbg.value and replace them with dbg.declare. In the code being changed, the pass is trying to seek a valid location at which to insert the dbg.declare. It has to come after the value to which it applies (which isn't true of the dbg.value). So there's this little loop trying to move forward to find the right instruction before which to insert new stuff.

I was expecting getNextNode to return null when there is no next node. When called on a terminator, it actually returns a non-null but malformed instruction pointer. So we have to explicitly check for terminators in this loop.

This really short basic block tripped up the pass:

; <label>:274                                     ; preds = %.lr.ph55
  %RawBufferLoad = call %dx.types.ResRet.i32 @dx.op.rawBufferLoad.i32(i32 139, %dx.types.Handle %lightBuffer_texture_structbuf, i32 %lightIndex.0, i32 28, i8 1, i32 4), !dbg !384
  %275 = extractvalue %dx.types.ResRet.i32 %RawBufferLoad, 0, !dbg !384
  switch i32 %275, label %288 [
    i32 0, label %276
    i32 1, label %280
    i32 2, label %284
  ], !dbg !397
I think the pass could be smarter about seeking the right insertion point for the dbg.declare. It's currently assuming that the dbg.value always succeeds the value to which it refers, but as in this case, that's not always true. But that's a project for another day.

(cherry picked from commit 650de80)
@hekota hekota requested a review from pow2clk June 30, 2021 21:48
Copy link
Member

@pow2clk pow2clk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks familiar! 😄

@AppVeyorBot
Copy link

@jeffnn jeffnn merged commit dad1cfc into microsoft:release-1.6.2106 Jun 30, 2021
@jeffnn jeffnn deleted the release-1.6.2106 branch June 30, 2021 22:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants