Incorrect sample profiles at O3

[llvmbot]

Bugzilla Link	28991
Version	trunk
OS	Linux
Attachments	Tar file of script and input files
Reporter	LLVM Bugzilla Contributor
CC	@vns-mn,@hfinkel,@rotateright

Extended Description

bug2.sh generates the reproduction where we compile a training program either -00 or -03.

The -O0 training yield this sample

Function: _Z8clampSumPdidd: 105434939, 1, 14 sampled lines Samples collected in the function's body { 0: 1 1: 1 2.1: 949899 2.2: 949797 3: 949833 4: 0 5: 949926 6: 949896 7: 0 8: 949929 9: 949904 11: 949889 12: 949809 14: 4 }

while the -O3 training yields this sample

Function: _Z8clampSumPdidd: 76108151, 2, 9 sampled lines Samples collected in the function's body { 0: 2 2.1: 1435907 3: 1436091 6: 1436048 7: 1436032 9: 2 11: 1435984 12: 1435974 14: 2 }

Note the differences in values for relative statements 7 and 9. The corresponding branch_weights are !​74 = !{!"branch_weights", i32 1, i32 949905} and !​74 = !{!"branch_weights", i32 1436033, i32 3}

The -O3 sample inverts the relative weights relative to the (correct) -O0 sample.

The attached tar file has bug2.sh, bug.cc and main.cc and a snapshot of bug2.sh output.

[rotateright]

Also, in CodeGen Prepare, there is code that attempts to undo a select based on branch weights. isFormingBranchFromSelectProfitable(). Getting this wrong compromises hmmer in Spec2006

Can you file a separate bug for that (ideally with a reduced test case)? Thanks!

[llvmbot]

Also, in CodeGen Prepare, there is code that attempts to undo a select based on branch weights. isFormingBranchFromSelectProfitable(). Getting this wrong compromises hmmer in Spec2006

[david-xl]

Re #​3 -- to clarify : if ifcvt uses profile data to make decision and do not convert highly biased branch, then bad profile can have bigger impact.

[david-xl]

Code layout can be bad with this

[llvmbot]

This is an interesting case: the branch weights become opposite in optimized binary.

But for this case, neither LICM nor if-conversion replies on profile data. As a result, the same optimization will take place no matter how wrong the profile is when profile is used. And after if-conversion, the profile correctness would not matter at all for later optimizations. So I think we should be able to live with the incorrect profile?

[llvmbot]

When SimplifyCFG speculates the execution of a block, the statements in that block will have execution frequency raise to that of the dominating block. For the "then" clause this raises the frequency from 0 to a same as the trip count of the loop.

The same thing would happen to the "else" block but in this case the operations are loop invariant and so get housed out of the loop and instead of getting the same frequency as the loop body, they the much lower estimate of the loop header.