[llvm] r205379 - [ARM64][CollectLOH] Add some comments to explain how the LOHs

[Quentin Colombet]

Hi James,

On Apr 2, 2014, at 3:17 AM, James Molloy <james at jamesmolloy.co.uk> wrote:

> Hi Quentin,
> 
> Thanks for adding those extra comments. However, I believe LLVM policy is to not have Apple rdar:// links at all in the source code. Could you therefore remove these lines?
Sure!

Here you go:
Committed revision 205435.

Thanks,
-Quentin
> 
>  // More information are available in the design document attached to
>  // rdar://11956674
> 
> Thanks,
> 
> James
> 
> 
> On 2 April 2014 02:02, Quentin Colombet <qcolombet at apple.com> wrote:
> Author: qcolombet
> Date: Tue Apr  1 20:02:28 2014
> New Revision: 205379
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=205379&view=rev
> Log:
> [ARM64][CollectLOH] Add some comments to explain how the LOHs
> framework works (for the compiler part), since the design
> document is not available.
> 
> Modified:
>     llvm/trunk/lib/MC/MCLinkerOptimizationHint.cpp
>     llvm/trunk/lib/Target/ARM64/ARM64CollectLOH.cpp
> 
> Modified: llvm/trunk/lib/MC/MCLinkerOptimizationHint.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/MCLinkerOptimizationHint.cpp?rev=205379&r1=205378&r2=205379&view=diff
> ==============================================================================
> --- llvm/trunk/lib/MC/MCLinkerOptimizationHint.cpp (original)
> +++ llvm/trunk/lib/MC/MCLinkerOptimizationHint.cpp Tue Apr  1 20:02:28 2014
> @@ -14,6 +14,14 @@
> 
>  using namespace llvm;
> 
> +// Each LOH is composed by, in this order (each field is encoded using ULEB128):
> +// - Its kind.
> +// - Its number of arguments (let say N).
> +// - Its arg1.
> +// - ...
> +// - Its argN.
> +// <arg1> to <argN> are absolute addresses in the object file, i.e.,
> +// relative addresses from the beginning of the object file.
>  void MCLOHDirective::Emit_impl(raw_ostream &OutStream,
>                                 const MachObjectWriter &ObjWriter,
>                                 const MCAsmLayout &Layout) const {
> 
> Modified: llvm/trunk/lib/Target/ARM64/ARM64CollectLOH.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM64/ARM64CollectLOH.cpp?rev=205379&r1=205378&r2=205379&view=diff
> ==============================================================================
> --- llvm/trunk/lib/Target/ARM64/ARM64CollectLOH.cpp (original)
> +++ llvm/trunk/lib/Target/ARM64/ARM64CollectLOH.cpp Tue Apr  1 20:02:28 2014
> @@ -11,7 +11,42 @@
>  // This pass should be run at the very end of the compilation flow, just before
>  // assembly printer.
>  // To be useful for the linker, the LOH must be printed into the assembly file.
> -// Currently supported LOH are:
> +//
> +// A LOH describes a sequence of instructions that may be optimized by the
> +// linker.
> +// This same sequence cannot be optimized by the compiler because some of
> +// the information will be known at link time.
> +// For instance, consider the following sequence:
> +//     L1: adrp xA, sym at PAGE
> +//     L2: add xB, xA, sym at PAGEOFF
> +//     L3: ldr xC, [xB, #imm]
> +// This sequence can be turned into:
> +// A literal load if sym at PAGE + sym at PAGEOFF + #imm - address(L3) is < 1MB:
> +//     L3: ldr xC, sym+#imm
> +// It may also be turned into either the following more efficient
> +// code sequences:
> +// - If sym at PAGEOFF + #imm fits the encoding space of L3.
> +//     L1: adrp xA, sym at PAGE
> +//     L3: ldr xC, [xB, sym at PAGEOFF + #imm]
> +// - If sym at PAGE + sym at PAGEOFF - address(L1) < 1MB:
> +//     L1: adr xA, sym
> +//     L3: ldr xC, [xB, #imm]
> +//
> +// To be valid a LOH must meet all the requirements needed by all the related
> +// possible linker transformations.
> +// For instance, using the running example, the constraints to emit
> +// ".loh AdrpAddLdr" are:
> +// - L1, L2, and L3 instructions are of the expected type, i.e.,
> +//   respectively ADRP, ADD (immediate), and LD.
> +// - The result of L1 is used only by L2.
> +// - The register argument (xA) used in the ADD instruction is defined
> +//   only by L1.
> +// - The result of L2 is used only by L3.
> +// - The base address (xB) in L3 is defined only L2.
> +// - The ADRP in L1 and the ADD in L2 must reference the same symbol using
> +//   @PAGE/@PAGEOFF with no additional constants
> +//
> +// Currently supported LOHs are:
>  // * So called non-ADRP-related:
>  //   - .loh AdrpAddLdr L1, L2, L3:
>  //     L1: adrp xA, sym at PAGE
> @@ -39,12 +74,28 @@
>  //   L1 result is used only by L2 and L2 result by L3.
>  //   L3 LOH-related argument is defined only by L2 and L2 LOH-related argument
>  //   by L1.
> +// All these LOHs aim at using more efficient load/store patterns by folding
> +// some instructions used to compute the address directly into the load/store.
>  //
>  // * So called ADRP-related:
>  //  - .loh AdrpAdrp L2, L1:
>  //    L2: ADRP xA, sym1 at PAGE
>  //    L1: ADRP xA, sym2 at PAGE
>  //    L2 dominates L1 and xA is not redifined between L2 and L1
> +// This LOH aims at getting rid of redundant ADRP instructions.
> +//
> +// The overall design for emitting the LOHs is:
> +// 1. ARM64CollectLOH (this pass) records the LOHs in the ARM64FunctionInfo.
> +// 2. ARM64AsmPrinter reads the LOHs from ARM64FunctionInfo and it:
> +//     1. Associates them a label.
> +//     2. Emits them in a MCStreamer (EmitLOHDirective).
> +//         - The MCMachOStreamer records them into the MCAssembler.
> +//         - The MCAsmStreamer prints them.
> +//         - Other MCStreamers ignore them.
> +//     3. Closes the MCStreamer:
> +//         - The MachObjectWriter gets them from the MCAssembler and writes
> +//           them in the object file.
> +//         - Other ObjectWriters ignore them.
>  //
>  // More information are available in the design document attached to
>  // rdar://11956674
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140402/39e3f03e/attachment.html>