From 556ca272fb3e9264fe96b92329e80ffb9b85a1e3 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Mon, 27 Jul 2009 18:07:55 +0000 Subject: Following discussion on llvm-dev ("proposed new rule for getelementptr"), add a new "Pointer Aliasing Rules" section. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77216 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/LangRef.html | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) (limited to 'docs') diff --git a/docs/LangRef.html b/docs/LangRef.html index 9ab62c0349..7858e6373d 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -48,6 +48,7 @@
  • Garbage Collector Names
  • Module-Level Inline Assembly
  • Data Layout
  • +
  • Pointer Aliasing Rules
  • Type System @@ -1243,6 +1244,54 @@ target datalayout = "layout specification" + + + +
    + +

    Any memory access must be done though a pointer value associated +with with address range of the memory access, otherwise the behavior +is undefined. Pointer values are associated with address ranges +according to the following rules:

    + +
      +
    • A pointer value formed from a getelementptr instruction is + associated with the addresses associated with the first operand of + the getelementptr.
    • +
    • An addresses of a global variable is associated with the address + range of the variable's storage.
    • +
    • The result value of an allocation instruction is associated with + the address range of the allocated storage.
    • +
    • A null pointer in the default address-space is associated with + no addresses.
    • +
    • A pointer value formed by an inttoptr is associated with + all address ranges of all pointer values that contribute (directly + or indirectly) to the computation of the pointer's value.
    • +
    • The result value of a bitcast is associated with all + addresses associated with the operand of the bitcast.
    • +
    • An integer constant other than zero or a pointer value returned + from a function not defined within LLVM may be associated with address + ranges allocated through mechanisms other than those provided by + LLVM. Such ranges shall not overlap with any ranges of address + allocated by mechanisms provided by LLVM.
    • +
    + +

    LLVM IR does not associate types with memory. The result type of a +load merely indicates the size and alignment of the memory from +which to load, as well as the interpretation of the value. The first +operand of a store similarly only indicates the size and +alignment of the store.

    + +

    Consequently, type-based alias analysis, aka TBAA, aka +-fstrict-aliasing, is not applicable to general unadorned +LLVM IR. Metadata may be used to encode +additional information which specialized optimization passes may use +to implement type-based alias analysis.

    + +
    + -- cgit v1.2.3