[llvm-bugs] [Bug 42413] New: New byval verification check fails after PGO indirect call promotion pass

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=42413

            Bug ID: 42413
           Summary: New byval verification check fails after PGO indirect
                    call promotion pass
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Miscellaneous Instrumentation passes
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: llvm-bugs at lists.llvm.org, t.p.northover at gmail.com,
                    xur at google.com

Consider this test case:

; t.ll
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
%struct.Foo.1 = type { i32 }
%struct.Foo.2 = type { i32 }
@foo = common global i32 (%struct.Foo.2*)* null, align 8
define i32 @func4(%struct.Foo.1* byval(%struct.Foo.1) %p) {
entry:
  %gep = getelementptr inbounds %struct.Foo.1, %struct.Foo.1* %p, i32 0, i32 0
  %v = load i32, i32* %gep
  ret i32 %v
}
define i32 @bar(%struct.Foo.2* %f2) {
entry:
  %tmp = load i32 (%struct.Foo.2*)*, i32 (%struct.Foo.2*)** @foo, align 8
  %call = call i32 %tmp(%struct.Foo.2* byval(%struct.Foo.2) %f2), !prof !1
  ret i32 %call
}
!1 = !{!"VP", i32 0, i64 1600, i64 7651369219802541373, i64 1030, i64
-4377547752858689819, i64 410, i64 -6929281286627296573, i64 150, i64
-2545542355363006406, i64 10}

$ opt -pgo-icall-prom -S < t.ll -icp-total-percent-threshold=50
Attribute 'byval' type does not match parameter!
  %2 = call i32 @func4(%struct.Foo.1* byval(%struct.Foo.2) %1)
in function bar

The issue is that llvm::promoteCall in
llvm/lib/Transforms/Utils/CallPromotion.cpp simply mutates the function type
and inserts pointer casts as necessary, without considering the recently added
byval attribute type.

The question is, is the verifier check too strict? Should the IR produced by
this pass be invalid? In the desired end state, pointers will not have types,
and this code won't have to insert pointer casts, and the verifier won't even
be able to compare the byval types. I think we're in an intermediate state. For
now, we can of course update the code, but I felt it was worth filing a bug to
consider the larger issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190626/51c65578/attachment.html>