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

[Cameron McInally via llvm-dev]

On Fri, Jun 14, 2019 at 6:58 PM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Jun 14, 2019, at 3:24 PM, Eli Friedman via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> See https://reviews.llvm.org/D63036
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D63036&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=HPH8LbjOYmP3G9p6HJYKLtOFGQQJ0aWeEc7QU46PkOw&s=Q-PK-STEJTkFgcTQeOjIR7RY4e_iIHz191Qk_8syQlA&e=>
>  for the full patch and description. Essentially, the Constant::canTrap
> API is going away.  To make this work, the semantics of division and
> remainder constant expressions are changing slightly, so division by zero
> produces poison, not undefined behavior.  (The corresponding instructions
> still have undefined behavior.)  This change should make writing and
> understanding IR optimizations easier.
>
>
> Is anyone interested and willing to make a more profound change to llvm’s
> constants?  We should really remove all the trapping operators.  The only
> reason they exist in the first place is to allow use of Constant::get() as
> a high level constant folding API.  We could replace that, eliminate the
> trapping operators, and thus eliminate a ton of complexity and bugs…
>

Hi Chris,

If I'm understanding your proposal correctly, the constrained FP intrinsic
work could make use of that code -- in the future. Eventually we'll want to
optimize the constrained FP intrinsics and being able to constant fold
non-trapping instructions is important.

-Cam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190614/776a66ff/attachment.html>