RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-26 12:50:30 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

[LangRef] Clarify semantics of load metadata.

Browse Source 
We need to explicitly state what happens when an invariant promised by
load metadata is violated at runtime, since it's come up repeatedly.

It's possible we want to specify that the result of the load is poison
in some cases, rather than undefined behavior, if the constraint is
violated. That would allow preserving the metadata when the load is
hoisted, but doesn't allow propagating metadata based on control flow.
We currently do transforms based on control flow for nonnull metadata
(in PromoteMemToReg).

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

llvm-svn: 337325
This commit is contained in:
Eli Friedman 2018-07-17 20:38:11 +00:00
parent 1caf103655
commit b27e787f6c
1 changed files with 12 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
docs/LangRef.rst
View File

@ -4941,10 +4941,11 @@ representing the maximum relative error, for example:
``range`` metadata may be attached only to ``load``, ``call`` and ``invoke`` of
integer types. It expresses the possible ranges the loaded value or the value
returned by the called function at this call site is in. The ranges are
represented with a flattened list of integers. The loaded value or the value
returned is known to be in the union of the ranges defined by each consecutive
pair. Each pair has the following properties:
returned by the called function at this call site is in. If the loaded or
returned value is not in the specified range, the behavior is undefined. The
ranges are represented with a flattened list of integers. The loaded value or
the value returned is known to be in the union of the ranges defined by each
consecutive pair. Each pair has the following properties:
- The type must match the type loaded by the instruction.
- The pair ``a,b`` represents the range ``[a,b)``.
@ -7945,7 +7946,8 @@ metadata name ``<index>`` corresponding to a metadata node with no
entries. If a load instruction tagged with the ``!invariant.load``
metadata is executed, the optimizer may assume the memory location
referenced by the load contains the same value at all points in the
program where the memory location is known to be dereferenceable.
program where the memory location is known to be dereferenceable;
otherwise, the behavior is undefined.
The optional ``!invariant.group`` metadata must reference a single metadata name
``<index>`` corresponding to a metadata node with no entries.
@ -7955,9 +7957,9 @@ The optional ``!nonnull`` metadata must reference a single
metadata name ``<index>`` corresponding to a metadata node with no
entries. The existence of the ``!nonnull`` metadata on the
instruction tells the optimizer that the value loaded is known to
never be null. This is analogous to the ``nonnull`` attribute
on parameters and return values. This metadata can only be applied
to loads of a pointer type.
never be null. If the value is null at runtime, the behavior is undefined.
This is analogous to the ``nonnull`` attribute on parameters and return
values. This metadata can only be applied to loads of a pointer type.
The optional ``!dereferenceable`` metadata must reference a single metadata
name ``<deref_bytes_node>`` corresponding to a metadata node with one ``i64``
@ -7984,7 +7986,8 @@ The existence of the ``!align`` metadata on the instruction tells the
optimizer that the value loaded is known to be aligned to a boundary specified
by the integer value in the metadata node. The alignment must be a power of 2.
This is analogous to the ''align'' attribute on parameters and return values.
This metadata can only be applied to loads of a pointer type.
This metadata can only be applied to loads of a pointer type. If the returned
value is not appropriately aligned at runtime, the behavior is undefined.
Semantics:
""""""""""