LangRef: mention MSan's problem with speculative conditional branches.

[eugenis]

Summary

This short blurb aims to disallow optimizations like we had to revert
(under MSan) in

https://reviews.llvm.org/D21165
https://bugs.llvm.org/show_bug.cgi?id=28054
https://reviews.llvm.org/D67205

[lebedev.ri]

llvm/docs/LangRef.rst

3250 ↗

(On Diff #219000)

s/ex./e.g./

3255–3256 ↗

(On Diff #219000)

This doesn't parse.
Either "valid ... at least one defined bit", or "invalid ,,, at least one undefined bit"

[eugenis]

.

llvm/docs/LangRef.rst

3255–3256 ↗

(On Diff #219000)

We don't care about executions where the condition is defined.
When it is not, the new code has a side effect, therefore the original code needs to have a side effect too.

[efriedma]

LGTM

llvm/trunk/docs/LangRef.rst

.. code-block:: text
     b: unreachable
 
 A store *of* an undefined value can be assumed to not have any effect;
 we can assume that the value is overwritten with bits that happen to
 match what was already there. However, a store *to* an undefined
 location could clobber arbitrary memory, therefore, it has undefined
 behavior.
 
+**MemorySanitizer**, a detector of uses of uninitialized memory,
+defines a branch with condition that depends on an undef value (or
+certain other values, like e.g. a result of a load from heap-allocated
+memory that has never been stored to) to have an externally visible
+side effect. For this reason functions with *sanitize_memory*
+attribute are not allowed to produce such branches "out of thin
+air". More strictly, an optimization that inserts a conditional branch
+is only valid if in all executions where the branch condition has at
+least one undefined bit, the same branch condition is evaluated in the
+input IR as well.
+
 .. _poisonvalues:
 
 Poison Values
 -------------
 
 In order to facilitate speculative execution, many instructions do not
 invoke immediate undefined behavior when provided with illegal operands,
 and return a poison value instead.