Stream: t-compiler

Topic: wtf codegen, again?


nagisa (Dec 01 2018 at 15:15, on Zulip):
define i32 @caller() unnamed_addr #0 {
start:
  %0 = call i1 @llvm.expect.i1(i1 false, i1 false)
  br i1 %0, label %panic.i, label %callee.exit

panic.i:                                          ; preds = %start
; call core::panicking::panic
  call void @_ZN4llvm9panicking5panic17h58fdea4fa7a9abc8E({ [0 x i64], { [0 x i8]*, i64 }, [0 x i64], { [0 x i8]*, i64 }, [0 x i32], i32, [0 x i32], i32, [0 x i32] }* noalias readonly dereferenceable(40) bitcast ({ { [0 x i8]*, i64 }, { [0 x i8]*, i64 }, i32, i32 }* @panic_loc.2 to { [0 x i64], { [0 x i8]*, i64 }, [0 x i64], { [0 x i8]*, i64 }, [0 x i32], i32, [0 x i32], i32, [0 x i32] }*))
  unreachable

callee.exit:                                      ; preds = %start
  br label %bb1

bb1:                                              ; preds = %callee.exit
  ret i32 8
rkruppe (Dec 01 2018 at 15:16, on Zulip):

does another run of -instcombine -simplifycfg clean that up?

nagisa (Dec 01 2018 at 15:17, on Zulip):

now that’s some weird codegen haha, though note that this occurs with -Copt-level=0 only for code as such:

#[inline(always)]
fn callee() -> u32 { 4 + 4}
fn caller() -> u32 { callee() }
nagisa (Dec 01 2018 at 15:19, on Zulip):

does another run of -instcombine -simplifycfg clean that up?

I’m sure it would, but the point is that we end up with some weird IR without optimisations… well, I’ve been told we run inliner at -Copt-level=0, but still...

rkruppe (Dec 01 2018 at 15:20, on Zulip):

Ok I thought this was after -O2 and thus a pass ordering issue. -O0 is weird (what's the assume for anyway?) but I could see it happening from a combinations of MIR optz not finishing the job and IRBuilder constant folding

rkruppe (Dec 01 2018 at 15:22, on Zulip):

oh derp, expect, not assume, so it's expecting the integer overflow to not happen. and IRBuilder constant folds it to not happen, I guess

Last update: Nov 22 2019 at 04:50UTC