Add back the missing tests

Fixed diff discrepancy, removed asserts for structs/arrays/vectors, updated doc

Addressed some review comments, moved parsing of mtocdata options to AIX.cpp

Addressed review comments

Added diagnostic for when -mtocdata is used with -mcmodel=large

Addressed latest review comments

Rebase and fix last test case (remove include)

Addressed most of the review suggestions (except for the include)

You can use -### to dump cc1 options and find the useful one for your %clang_cc1 command.

%clang and %clang++ are normally only for test/Driver. Use %clang_cc1 for codegen tests.

Added TargetSpecific flag, updated some comments.

Updated clang doc, added assert

@lebedev.ri
Hi again
Seeing as the patch doesn't seem as straightforward as originally thought and people have been opposed to it, do you think it might be better to revert your initial commit until there's a fix everyone is happy with?

LGTM. My main previous concern has been addressed by the {{.*}}

Thanks; my suggestion regarding the location was just a guess, I think you're right that it might not be the problem. Unless someone else brings it up, it's fine to leave it as it is.
I'm not sure if I can share specific details so I'll err on the side of caution and won't. But basically I'll just say it was a very minor change in the expected PGO struct (after the private global).
Yes, autogenerated tests are convenient, but the drawback is that these tests check all of the lines not just what is relevant to the original commit so these test cases are fragile.

Actually, I figured out a way around this failure by slightly modifying the expected output. So no further need for changes here.
Fyi in the future it would be helpful if we just have .* in places that aren't relevant to what the test is supposed to be testing, to avoid issues like this.
Thanks!

Hi @paulkirth
The test llvm/test/Transforms/PGOProfile/prof_avoid_relocs.ll causes a failure on my end with Power. I see that you have a target triple with X86 in it, so I'm wondering if this should be moved to the X86 directory. Or alternatively, you could do what you did in llvm/test/Transforms/PGOProfile/comdat.ll and use regular expressions for the part after "private global," the should fix it too.

Hi @lebedev.ri
I noticed it's been a while since the last review comment in your patch for the issue I reported last month; just wondering if you could ping them again so we can get this resolved. Alternatively, if you think it'll take a while, please revert your initial commit.

This commit seems to increase the cost for expanding trip count scev leading to some loops prevented from being unrolled. For example, in the test case below:

• Prior to this commit isHighCostExpansionHelper returns false (the computed cost 3 < the budget 4) and the loop is unrolled by 8
• Following the commit, isHighCostExpansionHelper returns true (the computed cost 5 > the budget 4) and the loop is no longer unrolled

Please revert the commit until you have a fix ready.

@nikic I'm just wondering if you had a chance to push my commit through

In D136095#3898515, @nikic wrote:

@alexgatea Can you please share Name <email> to use for the commit?

Updated test name

@nikic Thanks for approving! Since this is my first approved patch, I don't think I have commit access. So can you please push it for me (or let me know if I'm wrong)?

Updated the patch with the suggested fix, and updated my LIT test as well as the LIT test from the previous patch. I agree that this is a better approach than my initial try.

Updated LIT test to the suggested reduced test case.

Fyi the build fails due to clang-format, but I checked locally and the improperly formatted lines are not related to my patch

In D135451#3871711, @arsenm wrote:

In D135451#3859075, @alexgatea wrote:

In D135451#3849697, @arsenm wrote:

Could you instead insert a clamp of the divisor and then pattern match that out during selection?

Hmm not sure what you mean by selection. Could you please elaborate (perhaps with an example)?

If you speculate sdiv x, y, replace it with sdiv x, (y == 0 ? 1 : y) or whatever behavior you get for this case. In your backend, then pattern match the divide by 0 check when selecting to the instruction

Thank you for all the comments and suggestions! Closing this PR since the consensus is that using a TTI hook to create target-specific IR semantics is undesirable.

Changed to full context differential and provided more information in the description

In D135451#3849697, @arsenm wrote:

Could you instead insert a clamp of the divisor and then pattern match that out during selection?

In D135451#3843081, @fhahn wrote:

In D135451#3843064, @alexgatea wrote:

In D135451#3842992, @fhahn wrote:

IIUC this proposal would effectively re-define udiv and urem's semantics on the IR level to not have undefined behavior for PPC?

I don't think that's quite correct. We still view them as undefined, it's just that we allow further optimizations to happen that we previously bailed out of. The example I gave shows exactly this; without the speculative execution the div is still hoisted to the preheader, but this is done much later in the pipeline by MachineLICM so we do not optimize it fully (because IndVarSimplifyPass occurs earlier).

Right, but the reason MachineLICM can do this today is because at this point we are dealing with machine instructions.

In terms of LLVM IR semantics, this change would allow hoisting an instruction that may produce UB into a path that didn't have UB before AFAICT.

In D135451#3842992, @fhahn wrote:

IIUC this proposal would effectively re-define udiv and urem's semantics on the IR level to not have undefined behavior for PPC?

It should be fixed in https://reviews.llvm.org/D133847

Ah I didn't see that. Thank you!

Hi
This test case is still failing for me due to the lines without -fuse-ld=ldd:

In D132913#3786734, @python3kgae wrote:

In D132913#3786679, @alexgatea wrote:

Thanks for reporting the issue.
But I cannot repro the fail.
Do you mind sharing your cmake command?

Hmm, I'm just running the command in the test case:
clang --driver-mode=dxc -Tlib_6_7 -fcgl -Fo - clang/test/CodeGenHLSL/float3.hlsl | FileCheck clang/test/CodeGenHLSL/float3.hlsl

This is the output I got with clang --driver-mode=dxc -Tlib_6_7 -fcgl -Fo - clang/test/CodeGenHLSL/float3.hlsl

target datalayout = "e-m:e-p:32:32-i1:32-i8:8-i16:16-i32:32-i64:64-f16:16-f32:32-f64:64-n8:16:32:64"
target triple = "dxil-unknown-shadermodel6.7-library"

; Function Attrs: noinline nounwind optnone
define noundef <3 x float> @"?foo@@YAT?$__vector@M$02@__clang@@T12@@Z"(<3 x float> noundef %a) #0 {
entry:
  %a.addr = alloca <3 x float>, align 16
  store <3 x float> %a, ptr %a.addr, align 16
  %0 = load <3 x float>, ptr %a.addr, align 16
  ret <3 x float> %0
}

attributes #0 = { noinline nounwind optnone "frame-pointer"="all" "min-legal-vector-width"="96" "no-trapping-math"="true" "stack-protector-buffer-size"="8" }

!llvm.module.flags = !{!0, !1}
!dx.valver = !{!2}
!llvm.ident = !{!3}

!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 7, !"frame-pointer", i32 2}
!2 = !{i32 1, i32 7}
!3 = !{!"clang version 16.0.0 (https://github.com/llvm/llvm-project c9d2b6b92d6c29d00f6adc0527cf2331dbaae31a)"}

Maybe you build clang with a different setting? What are the CMake options you're using?

Thanks for reporting the issue.
But I cannot repro the fail.
Do you mind sharing your cmake command?

This test fails because the actual output has <3 x float>* rather than ptr. Could you please fix this test case?

In D133275#3772570, @aeubanks wrote:

I don't think we need to worry about SPEC too much, just resolve regressions

LGTM

In D129599#3753699, @drcut wrote:

@alexgatea please try whether the new revision could solve your problem. Thanks

In D129599#3749469, @aeubanks wrote:

we can change the condition to if the function is cold

In D129599#3749005, @drcut wrote:

@alexgatea Thanks for the feedback.
isColdBlock should be global. One example is in (https://llvm.org/doxygen/ProfileSummaryInfo_8cpp_source.html#l00142), which uses isColdBlock to check whether a function is cold or not. So I assume the issue is the loop is non-cold in real case, but was concerned as cold in the profile data. I kindly suggest updating the profile data to see if there is still any degradation.
Please correct me if I am wrong. Thanks

I noticed significant performance degradation (~30%) on a spec benchmark due to this commit. isColdBlock doesn't seem to work as expected, because it considered cold a loop that was in a hot function through the profile.

When I compile the following valid test case:

I don't recognize those as tests in flang; do you have a link to the failures? It is highly unlikely that a change to Fortran semantics would affect any test not involving flang.

Just want to give you a heads-up that there are 3 LIT failures for to this commit:
TestCases/Linux/asan_dlopen_test.cpp
TestCases/Integer/sub-overflow.cpp
TestCases/Integer/uadd-overflow.cpp
Please investigate.