[llvm-dev] Planned change to IR semantics: constant expressions never have undefined behavior
Chris Lattner via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 14 20:44:20 PDT 2019
On Jun 14, 2019, at 6:41 PM, Eli Friedman <efriedma at quicinc.com> wrote:
> A better thing to do is to make ConstExpr’s have their own enum of “operations”, and make them correspond to the things that show up in a global variable initializer (e.g. relocatable expressions). There is no reason for constant expressions to mirror the instruction enum, and there is lots of harm caused by it.
> You may have lost me here, but that's ok. If you're suggesting not switching on the Instruction OpCodes in ConstantExpr::get(...) et al, to encapsulate the ConstantExpr class, then +1 from me.
> The idea here is actually to eliminate the underlying expressions themselves, so it would no longer be legal to write “sdiv (i32 […], i32 […])” as a constant expression at all in IR.
> The hardest part of this is probably figuring out how to handle AutoUpgrade;
Exactly. I haven’t actually tried this, but in my imagination, it isn’t too bad: there are three cases for a constant expr containing a div:
1) constant used by normal instruction: expand inline into the current block, and use the non constant value.
2) phi node: expand into the appropriate predecessor.
3) Global variable init or other thing: error, not supported by a backend anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev