Fix -Z lower_128bit_ops handling of statics

[scottmcm]

Avoids ICEs such as the following:

error: internal compiler error: src\librustc_metadata\cstore_impl.rs:131:
get_optimized_mir: missing MIR for DefId(8/0:40 ~ compiler_builtins[9532]::int[0]::addsub[0]::rust_i128_addo[0])

r? @nagisa

cc #45676 @est31

[hanna-kruppe]

Does this mean i128 ops won't get lowered in const fns at all? As const fns can run at runtime as well, I figure they'd have to be lowered for the run time version even if const eval can handle them.

[nagisa]

I think what should happen here is:

1. We make sure MIR gets included into compiler-builtins for i128 language items. This should happen within the compiler (so the change supposedly should be somewhere within the collector);
2. We make sure this pass gets run after constant propagation/miri runs, when those land.

[scottmcm]

I'm not certain what I should do here. rkruppe is absolutely right that this PR is just changing an unsoundness to an incompleteness.

(1) Getting the MIR for the lang items themselves seems insufficient, as I first tried #[inline]ing them, which then just complained about the things they were calling. So that feels wrong, especially as it may require getting the MIR for a some things in core, which shouldn't be affected by this.

(2) This sounds great, though I'm not sure where this pass would then run, since I figure const fns calling other const fns need this to not be applied, at which point it feels like it can't be in the normal "run these passes as part of generating final MIR for these functions". Is there a spot in trans where the pass could run? Or at that point does having this be done on MIR no longer make sense...

[nagisa]

@bors r+

[bors]

📌 Commit 1b88022 has been approved by nagisa

[bors]

⌛ Testing commit 1b8802224370abea71de246d80a2859b40aacdf1 with merge ec06e86fd1f0a30f558e94af4e8771a9a08fe890...

[arielb1]

@bors r- retry

I don't think this actually fixes things - now const fns will generate bad i128 ops when called in a non-constant context.

[arielb1]

I think the right way to fix it in the rustc_trans::mir::constant context would be to treat the i128 ops like intrinsics and "special-case-translate" them here:

rust/src/librustc_trans/mir/constant.rs

Lines 399 to 416 in 02b4d3d

	if let Some((ref dest, target)) = *destination {
	let result = if fn_ty.fn_sig(tcx).abi() == Abi::RustIntrinsic {
	match &tcx.item_name(def_id)[..] {
	"size_of" => {
	let llval = C_usize(self.ccx,
	self.ccx.size_of(substs.type_at(0)).bytes());
	Ok(Const::new(llval, tcx.types.usize))
	}
	"min_align_of" => {
	let llval = C_usize(self.ccx,
	self.ccx.align_of(substs.type_at(0)).abi());
	Ok(Const::new(llval, tcx.types.usize))
	}
	_ => span_bug!(span, "{:?} in constant", terminator.kind)
	}
	} else {
	MirConstContext::trans_def(self.ccx, def_id, substs, arg_vals)
	};

by calling the appropriate binary op implementation if the function def-id matches, via an inverse of the item_for_op function:

rust/src/librustc_mir/transform/lower_128bit.rs

Line 206 in 02b4d3d

fn item_for_op(bin_op: BinOp, is_signed: bool) -> Option<(LangItem, RhsKind)> {

[scottmcm]

Ok, updated to special-case-translate these calls in const trans. The inverse lookup can be found here: https://github.com/rust-lang/rust/pull/46583/files#diff-823b4422fff3f3018e53dfb6dc0a1fb3R468

[arielb1]

r? @eddyb - you know rustc_trans::mir::constant

[eddyb]

@bors r+

[bors]

📌 Commit 4b95ca8 has been approved by eddyb

[bors]

⌛ Testing commit 4b95ca8 with merge 7eb64b8...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing 7eb64b8 to master...