HomePhabricator

Add an @llvm.sideeffect intrinsic

Description

Add an @llvm.sideeffect intrinsic

This patch implements Chandler's idea [0] for supporting languages that
require support for infinite loops with side effects, such as Rust, providing
part of a solution to bug 965 [1].

Specifically, it adds an llvm.sideeffect() intrinsic, which has no actual
effect, but which appears to optimization passes to have obscure side effects,
such that they don't optimize away loops containing it. It also teaches
several optimization passes to ignore this intrinsic, so that it doesn't
significantly impact optimization in most cases.

As discussed on llvm-dev [2], this patch is the first of two major parts.
The second part, to change LLVM's semantics to have defined behavior
on infinite loops by default, with a function attribute for opting into
potential-undefined-behavior, will be implemented and posted for review in
a separate patch.

[0] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html
[1] https://bugs.llvm.org/show_bug.cgi?id=965
[2] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118632.html

Differential Revision: https://reviews.llvm.org/D38336

Details

Committed
djgNov 8 2017, 1:59 PM
Differential Revision
D38336: Add an @llvm.sideeffect intrinsic
Parents
rL317728: [ThinLTO] New test needs to require LTO
Branches
Unknown
Tags
Unknown

Event Timeline

I think it is a good idea to model the sideeffect intrinsic as "inaccessiblememonly"/"nounwind". That should already treat it as desired in most optimizations. I wonder if the additional special treatment of the intrinsic in optimizations here, is not already implied by these properties (or should be implied by these properties), especially when it comes after a failing test for e.g. mayReadOrWriteMemory() (i.e. inaccessiblememonly fails this, but normally the memory access is irrelevant to the optimization).

Treating the intrinsics as special cases in the optimizations risks to evolve in long tedious lists of ill-defined semantic exceptions. It is better IMHO if the exception can be raised into a property with a clear definition.