From 6154a01ceec9c034bf4407b0256faf538e23173e Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Mon, 27 Jul 2009 18:07:55 +0000 Subject: [PATCH] Following discussion on llvm-dev ("proposed new rule for getelementptr"), add a new "Pointer Aliasing Rules" section. llvm-svn: 77216 --- llvm/docs/LangRef.html | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/llvm/docs/LangRef.html b/llvm/docs/LangRef.html index 9ab62c0..7858e63 100644 --- a/llvm/docs/LangRef.html +++ b/llvm/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.

    + +
    + -- 2.7.4