Started 32 min ago
Took 30 min on green-dragon-24

Success Build #29324 (Jun 25, 2019 5:04:24 AM)

Build Artifacts
test_logs.tgz54.38 KB view
  • : 364297
  • : 364283
  • : 364276
  • : 363952
  • : 364241
  1. AMDGPU: Write LDS objects out as global symbols in code generation

    The symbols use the processor-specific SHN_AMDGPU_LDS section index
    introduced with a previous change. The linker is then expected to resolve
    relocations, which are also emitted.

    Initially disabled for HSA and PAL environments until they have caught up
    in terms of linker and runtime loader.

    Some notes:

    - The llvm.amdgcn.groupstaticsize intrinsics can no longer be lowered
      to a constant at compile times, which means some tests can no longer
      be applied.

      The current "solution" is a terrible hack, but the intrinsic isn't
      used by Mesa, so we can keep it for now.

    - We no longer know the full LDS size per kernel at compile time, which
      means that we can no longer generate a relevant error message at
      compile time. It would be possible to add a check for the size of
      individual variables, but ultimately the linker will have to perform
      the final check.

    Change-Id: If66dbf33fccfbf3609aefefa2558ac0850d42275

    Reviewers: arsenm, rampitec, t-tye, b-sumner, jsjodin

    Subscribers: qcolombet, kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by nha
  2. AMDGPU/MC: Add .amdgpu_lds directive

    The directive defines a symbol as an group/local memory (LDS) symbol.
    LDS symbols behave similar to common symbols for the purposes of ELF,
    using the processor-specific SHN_AMDGPU_LDS as section index.

    It is the linker and/or runtime loader's job to "instantiate" LDS symbols
    and resolve relocations that reference them.

    It is not possible to initialize LDS memory (not even zero-initialize
    as for .bss).

    We want to be able to link together objects -- starting with relocatable
    objects, but possible expanding to shared objects in the future -- that
    access LDS memory in a flexible way.

    LDS memory is in an address space that is entirely separate from the
    address space that contains the program image (code and normal data),
    so having program segments for it doesn't really make sense.

    Furthermore, we want to be able to compile multiple kernels in a
    compilation unit which have disjoint use of LDS memory. In that case,
    we may want to place LDS symbols differently for different kernels
    to save memory (LDS memory is very limited and physically private to
    each kernel invocation), so we can't simply place LDS symbols in a
    .lds section.

    Hence this solution where LDS symbols always stay undefined.

    Change-Id: I08cbc37a7c0c32f53f7b6123aa0afc91dbc1748f

    Reviewers: arsenm, rampitec, t-tye, b-sumner, jsjodin

    Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, rupprecht, llvm-commits

    Tags: #llvm

    Differential Revision: (detail)
    by nha

Started by timer

This run spent:

  • 3 ms waiting;
  • 30 min build duration;
  • 30 min total from scheduled to completion.
Test Result (no failures)