[llvm-dev] Landing Pad bug?

Johan Wehrli via llvm-dev
Tue, 11 Oct 2016 06:30:35 -0000

HI,

When compiling the open-source software cryptopp
(https://www.cryptopp.com/#download <https://www.cryptopp.com/#download>)
version 5.6.4 I found a strange issue with the IR generated.

The issue only appears when compiling with -O2 optimisation in the integer.cpp
file (the function is
_ZN8CryptoPPrsERNSt3__113basic_istreamIcNS0_11char_traitsIcEEEERNS_7IntegerE
-> CryptoPP::operator>>(std::__1::basic_istream<char,
std::__1::char_traits<char> >&, CryptoPP::Integer&)).

The verifier give me these errors:

EH pad cannot be in entry block. %4 = landingpad
{ i8*, i32 } cleanupLandingPadInst not the first non-PHI instruction in the
block. %4 = landingpad { i8*, i32 } cleanup

If I remove the verifier, I am able to compile the whole library and run the
test suite without any issue.

When you look at the whole IR code for the function:

----------------------

; Function Attrs: ssp uwtable
define nonnull dereferenceable(168) %"class.std::__1::basic_istream"*
@_ZN8CryptoPPrsERNSt3__113basic_istreamIcNS0_11char_traitsIcEEEERNS_7IntegerE(%"class.std::__1::basic_istream"*
dereferenceable(168), %"class.CryptoPP::Integer"* dereferenceable(40))
local_unnamed_addr #0 personality i8* bitcast (i32 (...)* @__gxx_personality_v0
to i8*) {
  %3 = tail call i8* @_ZN8CryptoPP17UnalignedAllocateEm(i64 16)
  %4 = landingpad { i8*, i32 }
          cleanup
  %5 = icmp eq i8* %3, null
  br i1 %5, label %6, label %8, !prof !22

; :6: ; preds = %2
  invoke void @__assert_rtn(i8* getelementptr inbounds ([11 x i8], [11 x i8]*
@__func__._ZN8CryptoPP20AllocatorWithCleanupIhLb0EE10deallocateEPvm, i64 0, i64
0), i8* getelementptr inbounds ([13 x i8], [13 x i8]* @.str.64, i64 0, i64 0),
i32 197, i8* getelementptr inbounds ([32 x i8], [32 x i8]* @.str.75, i64 0, i64
0)) #58
          to label %7 unwind label %10

; :7: ; preds = %6
  unreachable

; :8: ; preds = %2
  %9 = tail call { i64, i8* } asm sideeffect "rep stosb",
"={cx},={di},{ax},0,1,~{memory},~{dirflag},~{fpsr},~{flags}"(i32 0,
i64 16, i8* nonnull %3) #53, !srcloc !1070
  invoke void @_ZN8CryptoPP19UnalignedDeallocateEPv(i8* nonnull %3)
          to label %13 unwind label %10

; :10: ; preds = %8, %6
  %11 = landingpad { i8*, i32 }
          catch i8* null
  %12 = extractvalue { i8*, i32 } %11, 0
  tail call void @__clang_call_terminate(i8* %12) #59
  unreachable

; :13: ; preds = %8
  resume { i8*, i32 } %4
}

----------------------

I was not able to understand which optimisation transforms the code like this.

I have attached the IR code from the function in O0 and O2.

Greetings,

Johan



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: O0.ll
Type: application/octet-stream
Size: 12036 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: O2.ll
Type: application/octet-stream
Size: 1728 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161011/05f53e63/attachment-0002.html>