[llvm-dev] Landing Pad bug?

Johan Wehrli via llvm-dev
Wed, 12 Oct 2016 13:00:07 -0000

Hi Reid,

You can find the preprocess source here: https://reviews.llvm.org/P7928
<https://reviews.llvm.org/P7928>

This is the compile line used: llvm3.9/bin/clang++ -O2 integer.cpp -E &>
preprocess.txt

Greetings,

Johan

> On 11 Oct 2016, at 18:02, Reid Kleckner <rnk at google.com> wrote:
>
> That's an interesting bug. Can you post the pre-processed source code
somewhere? I can't optimize the O0.ll file because it only contains the
function, and none of the struct types.
>
> Usually pre-processed source is large, so I wouldn't recommend mailing
it to the list. I'd suggest our bugzilla, but you can't create new
accounts right now without mailing llvm-admin.
>
> On Mon, Oct 10, 2016 at 11:30 PM, Johan Wehrli via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>wrote:
> 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
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/e2683cdd/attachment.html>