[llvm-bugs] [Bug 47060] New: PHI/Aggregate merging

[via llvm-bugs]

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

            Bug ID: 47060
           Summary: PHI/Aggregate merging
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: lebedev.ri at gmail.com
                CC: llvm-bugs at lists.llvm.org

I'm seeing roughly the following as remnants of clang C++ exception handling
on unwind branch:

https://godbolt.org/z/hxMTs6

declare void @something0()
declare void @something1()
declare void @something2()

define {i8*, i32} @square({i8*, i32} %arg0, {i8*, i32} %arg1, {i8*, i32} %arg2,
i1 %cond) {
entry:
  br i1 %cond, label %v0, label %v1

v0:
  %i121 = extractvalue { i8*, i32 } %arg0, 0
  %i122 = extractvalue { i8*, i32 } %arg0, 1
  call void @something0()
  br label %end

v1:
  %i1212 = extractvalue { i8*, i32 } %arg1, 0
  %i1222 = extractvalue { i8*, i32 } %arg1, 1
  call void @something1()
  br label %end

end:
  %exn.slot.4 = phi i8* [ %i121, %v0 ], [ %i1212, %v1 ]
  %ehselector.slot.4 = phi i32 [ %i122, %v0 ], [ %i1222, %v1 ]

  call void @something2()

  %lpad.val = insertvalue { i8*, i32 } undef, i8* %exn.slot.4, 0
  %lpad.val302 = insertvalue { i8*, i32 } %lpad.val, i32 %ehselector.slot.4, 1

  ret {i8*, i32} %lpad.val302
}


All that is redundant and should roughly just be:
https://godbolt.org/z/a6q1Ea

declare void @something0()
declare void @something1()
declare void @something2()

define {i8*, i32} @square({i8*, i32} %arg0, {i8*, i32} %arg1, {i8*, i32} %arg2,
i1 %cond) {
entry:
  br i1 %cond, label %v0, label %v1

v0:
  call void @something0()
  br label %end

v1:
  call void @something1()
  br label %end

end:
  %r = phi {i8*, i32} [ %arg0, %v0 ], [ %arg1, %v1 ]

  call void @something2()

  ret {i8*, i32} %r
}

If that happens, the resume block of an exception will be recognized as being
empty,
and invoke will be simplified into a call. (not depicted in examples,
see http://reviews.llvm.org/rGe492f0e03b01a5e4ec4b6333abb02d303c3e479e)

I guess, this is a missing fold in instcombine.
Question is: *what* fold is missing? How lax are we okay with it being?

The most simple solution is to look for 'insert of phi', where each incoming
value is an 'extract',
where types of the destination and source match and the lanes match, and just
merge all those extracts
into the block with insert, by forming a PHI for the sources of extracts and
extracting from said new PHI.
This will be rather simple do to.

If that happens for all new inserts, we already know how to fold the rest away:
https://godbolt.org/z/jcY1zo

More complicated (but more proper) solution would be to start looking from the
final insert,
and ensure that we can just replace chain of inserts with the PHI of extract
sources.

Do we want to go with the former or latter approach?

-- 
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/20200809/80e9a102/attachment.html>