[llvm-dev] Planned change to IR semantics: constant expressions never have undefined behavior

[Chris Lattner via llvm-dev]

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.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190614/be3c79e1/attachment-0001.html>