Fix ICE when compiling huge allocations with GVN enabled

[sgasho]

closes: #149643

I removed PANIC_ON_ALLOC_FAIL flag and introduced ALLOC_FAILURE_REPORTING enum whether to force-print allocation(whether to emit delayed_bug or not in this case) bug or not.

I checked that sample code in the issue has been compiled successfully without ICE.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[rustbot]

r? @adwinwhite

rustbot has assigned @adwinwhite.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, mir
• compiler, mir expanded to 69 candidates
• Random selection from 16 candidates

[RalfJung]

Please explain the idea behind this PR -- why replace the bool by an enum, and what exactly does the enum do?

[RalfJung]

I don't think we want three ways of creating an allocation. It's even more strange that the enum that decides which one we use has just two variants.

[sgasho]

why replace the bool by an enum, and what exactly does the enum do?

I'll remove the enum then just rename the bool name. I created three fields in it in my first implementation then removed one. I forgot to convert the enum back to bool 🙇

[adwinwhite]

r? miri

[RalfJung]

The "obvious" fix here is to just set this to false

rust/compiler/rustc_const_eval/src/const_eval/dummy_machine.rs

Line 52 in fab64de

const PANIC_ON_ALLOC_FAIL: bool = true;

Is there some reason that doesn't work? I haven't checked all consumers of DummyMachine.

[sgasho]

Is there some reason that doesn't work?

Just setting that to false doesn't work. rustc produces another ICE, saying "exhausted memory during interpretation", which is printed from delayed_bug on Allocation::try_new.

[sgasho]

I think moving delayed_bug out of try_new might work. I'll try to implement it

[RalfJung]

Hm... I think we added that delay_bug because successful queries have to be deterministic, and failing to allocate is not deterministic.

That actually would also apply to the GVN pass -- I'm not sure if it is sound to have the optimization sometimes work and sometimes not depending on whether we have enough RAM.

Cc @cjgillot @oli-obk

[sgasho]

So you mean we should turn this into a normal compilation failure instead of an ICE, and avoid silently continuing compilation when optimization failed due to OOM?

[sgasho]

Ah, looking at gvn.rs, many interpreter errors are dropped via discard_err()? I'm not fully sure about the intended policy there, so I'm less confident in my previous comment.

[RalfJung]

The best way I can imagine for fixing this is to simply not even try to create such large allocations during GVN -- just don't touch values that are too big. But maybe there's a good reason for us not having such a limit currently?

Cc @rust-lang/wg-mir-opt

[saethlin]

I think the fix here is to not have GVN try to ignore allocation failures. const-eval reports them, and GVN should too.

Yes GVN ignores a lot of errors, IIRC that's because MIR bodies may have type-checking or other kinds of errors in them when they are fed into the MIR opt pipeline.