This is an archive of the discontinued LLVM Phabricator instance.

[SelectionDAG][RISCV] Add preferred extend of value used for PHI node
AbandonedPublic

Authored by Luhaocong on Dec 30 2021, 1:01 AM.

Details

Summary

If a value is used for PHI node,and the PHI node is only used for return instruction which requires
signext or zeroext, we set default preferred extend kind to SIGN_EXTEND or ZERO_EXTEND.

With this optimization, we could perform bit extend in necessary BB,instead of return BB .
At the same time, increase more machine CSE opportunities.

Diff Detail

Unit TestsFailed

Event Timeline

Luhaocong created this revision.Dec 30 2021, 1:01 AM
Luhaocong requested review of this revision.Dec 30 2021, 1:01 AM
craig.topper retitled this revision from [SelectionDAG][RISCV] Add preferred entend of value used for PHI node to [SelectionDAG][RISCV] Add preferred extend of value used for PHI node.Dec 30 2021, 9:23 AM
craig.topper added inline comments.Dec 30 2021, 9:28 AM
llvm/test/CodeGen/RISCV/prefer-extend.ll
3

What does the S mean after RV32/RV64?

6

Remove the dso_local

jrtc27 added a comment.EditedDec 30 2021, 9:51 AM

The test case is quite complicated for what should be a simple thing to test. and is rather redundant in its IR; ignoring the nsw aspect, sext+sub+trunc is just sub of the smaller type, and the sext+icmp can just be icmp of the smaller type. Changing the latter seems to have no effect on the generated code, but for whatever reason changing the former to just sub on i16 already sign-extends at the computation site. Also, your ; preds comments don't belong in IR tests, and the naming looks like you just took Clang output and hacked it into a test.

define signext i16 @foo(i16 signext %a, i1 zeroext %b) {
entry:
  br i1 %b, label %add, label %ret

add:
  %0 = add i16 %a, 1
  br label %ret

ret:
  %1 = phi i16 [ %a, %entry ], [ %0, %add ]
  ret i16 %1
}

is a much simpler from-scratch test that should show the behaviour you want.

llvm/test/CodeGen/RISCV/prefer-extend.ll
3

I assume it's for signext, but that has no place here

With this optimization, we could perform bit extend in necessary BB,instead of all predecessors of
return BB. At the same time, increase more machine CSE opportunities.

Why would the extend be in all predecessors? Wouldn't it just be in the block with the return?

Wouldn't this patch increase code size if none of the phi inputs were known to be sign extended? Your test just moves an extend to the block that produced %conv2 because %left and %right are already extended. But if they weren't wouldn't it increase the number of extends?

Luhaocong updated this revision to Diff 397198.Jan 3 2022, 10:42 PM
Luhaocong edited the summary of this revision. (Show Details)
  1. fix failed test case.
  2. To avoid increasing the loop body, we exclude values within the loop,

The test case is quite complicated for what should be a simple thing to test. and is rather redundant in its IR; ignoring the nsw aspect, sext+sub+trunc is just sub of the smaller type, and the sext+icmp can just be icmp of the smaller type. Changing the latter seems to have no effect on the generated code, but for whatever reason changing the former to just sub on i16 already sign-extends at the computation site. Also, your ; preds comments don't belong in IR tests, and the naming looks like you just took Clang output and hacked it into a test.

define signext i16 @foo(i16 signext %a, i1 zeroext %b) {
entry:
  br i1 %b, label %add, label %ret

add:
  %0 = add i16 %a, 1
  br label %ret

ret:
  %1 = phi i16 [ %a, %entry ], [ %0, %add ]
  ret i16 %1
}

is a much simpler from-scratch test that should show the behaviour you want.

Thanks for your professional guidance,I will focus more on simplifying test cases

Luhaocong marked 3 inline comments as done.Jan 3 2022, 10:58 PM

With this optimization, we could perform bit extend in necessary BB,instead of all predecessors of
return BB. At the same time, increase more machine CSE opportunities.

Why would the extend be in all predecessors? Wouldn't it just be in the block with the return?

Wouldn't this patch increase code size if none of the phi inputs were known to be sign extended? Your test just moves an extend to the block that produced %conv2 because %left and %right are already extended. But if they weren't wouldn't it increase the number of extends?

It‘s my mistake, what I want to express is that not all paths to return BB should do the extend.
Sometimes this does increase code size, but I think it is valuable if you can get optimization opportunities.

llvm/test/CodeGen/RISCV/prefer-extend.ll
3

I've deleted it

6

Done

Luhaocong abandoned this revision.Feb 8 2022, 12:28 AM
Luhaocong marked an inline comment as done.