[PATCH] D18634: Don't IPO over functions that can be de-refined

[Sanjoy Das via llvm-commits]

sanjoy created this revision.
sanjoy added reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk.
sanjoy added a subscriber: llvm-commits.
Herald added a subscriber: mcrosier.

Fixes PR26774.

If you're aware of the issue, feel free to skip the "Motivation"
section and jump directly to "This patch".

Motivation:

I define "refinement" as discarding behaviors from a program that the
optimizer has license to discard.  So transforming:

```
void f(unsigned x) {
  unsigned t = 5 / x;
  (void)t;
}
```

to

```
void f(unsigned x) { }
```

is refinement, since the behavior went from "if x == 0 then undefined
else nothing" to "nothing" (the optimizer has license to discard
undefined behavior).

Refinement is a fundamental aspect of many mid-level optimizations
LLVM does.  For instance, transforming `x == (x + 1)` to `false` also
involves refinement since the expression's value went from "if x is
`undef` then { `true` or `false` } else { `false` }" to "`false`" (by
definition of `undef`, the optimizer has license to fold `undef` to
any non-`undef` value).

Unfortunately, refinement implies that the optimizer cannot assume
that the implementation of a function it can see has all of the
behavior an unoptimized or a differently optimized version of the same
function can have.  This is a problem for functions with comdat
linkage, where a function can be replaced by an unoptimized or a
differently optimized version of the same source level function.

For instance, FunctionAttrs cannot assume a comdat function is
actually `readnone` even if it does not have any loads or stores in
it; since there may have been loads and stores in the "original
function" that were refined out in the currently visible variant, and
at the link step the linker may in fact choose an implementation with
a load or a store.  As an example, consider a function that does two
atomic loads from the same memory location, and writes to memory only
if the two values are not equal.  The optimizer is allowed to refine
this function by first CSE'ing the two loads, and the folding the
comparision to always report that the two values are equal.  Such a
refined variant will look like it is `readonly`.  However, the
unoptimized version of the function can still write to memory (since
the two loads //can// result in different values), and selecting the
unoptimized version at link time will retroactively invalidate
transforms we may have done under the assumption that the function
does not write to memory.


This patch:

This change introduces a new set of linkaged types, predicated as
`GlobalValue::mayBeDerefined` that returns true if the linkage type
allows a function to be replaced by a differently optimized variant at
link time.  It then changes a set of IPO passes to bail out if they see
such a function.

http://reviews.llvm.org/D18634

Files:
  include/llvm/IR/GlobalValue.h
  lib/Analysis/GlobalsModRef.cpp
  lib/Transforms/IPO/DeadArgumentElimination.cpp
  lib/Transforms/IPO/FunctionAttrs.cpp
  lib/Transforms/IPO/IPConstantPropagation.cpp
  lib/Transforms/IPO/PruneEH.cpp
  lib/Transforms/ObjCARC/ObjCARCAPElim.cpp
  lib/Transforms/Scalar/SCCP.cpp
  test/Analysis/GlobalsModRef/comdat-ipo.ll
  test/Transforms/FunctionAttrs/comdat-ipo.ll
  test/Transforms/IPConstantProp/comdat-ipo.ll
  test/Transforms/ObjCARC/comdat-ipo.ll
  test/Transforms/SCCP/comdat-ipo.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D18634.52157.patch
Type: text/x-patch
Size: 13280 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160331/94ff6c0b/attachment.bin>