[all-commits] [llvm/llvm-project] 3bc415: Add a default address space for globals to DataLayout

[Alexander Richardson via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 3bc4157556b01e10288df120dd068e093ae20901
      https://github.com/llvm/llvm-project/commit/3bc4157556b01e10288df120dd068e093ae20901
  Author: Alex Richardson <Alexander.Richardson at cl.cam.ac.uk>
  Date:   2020-11-20 (Fri, 20 Nov 2020)

  Changed paths:
    M llvm/docs/LangRef.rst
    M llvm/include/llvm/IR/DataLayout.h
    M llvm/include/llvm/IR/GlobalVariable.h
    M llvm/lib/IR/DataLayout.cpp
    M llvm/lib/IR/Globals.cpp
    A llvm/test/Assembler/invalid-datalayout-globals-addrspace.ll
    M llvm/unittests/IR/DataLayoutTest.cpp

  Log Message:
  -----------
  Add a default address space for globals to DataLayout

This is similar to the existing alloca and program address spaces (D37052)
and should be used when creating/accessing global variables.
We need this in our CHERI fork of LLVM to place all globals in address space 200.
This ensures that values are accessed using CHERI load/store instructions
instead of the normal MIPS/RISC-V ones.

The problem this is trying to fix is that most of the time the type of
globals is created using a simple PointerType::getUnqual() (or ::get() with
the default address-space value of 0). This does not work for us and we get
assertion/compilation/instruction selection failures whenever a new call
is added that uses the default value of zero.

In our fork we have removed the default parameter value of zero for most
address space arguments and use DL.getProgramAddressSpace() or
DL.getGlobalsAddressSpace() whenever possible. If this change is accepted,
I will upstream follow-up patches to use DL.getGlobalsAddressSpace() instead
of relying on the default value of 0 for PointerType::get(), etc.

This patch and the follow-up changes will not have any functional changes
for existing backends with the default globals address space of zero.
A follow-up commit will change the default globals address space for
AMDGPU to 1.

Reviewed By: dylanmckay

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


  Commit: 51e09e1d5aa43296cf8baf26a74793fd86b0b0d2
      https://github.com/llvm/llvm-project/commit/51e09e1d5aa43296cf8baf26a74793fd86b0b0d2
  Author: Alex Richardson <Alexander.Richardson at cl.cam.ac.uk>
  Date:   2020-11-20 (Fri, 20 Nov 2020)

  Changed paths:
    M clang/lib/Basic/Targets/AMDGPU.cpp
    M clang/lib/CodeGen/CGClass.cpp
    M clang/lib/CodeGen/CGOpenMPRuntime.cpp
    M clang/lib/CodeGen/CGVTT.cpp
    M clang/lib/CodeGen/ItaniumCXXABI.cpp
    M clang/test/CodeGen/target-data.c
    M clang/test/CodeGenOpenCL/amdgpu-env-amdgcn.cl
    M llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
    M llvm/lib/IR/AutoUpgrade.cpp
    M llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
    M llvm/unittests/Bitcode/DataLayoutUpgradeTest.cpp

  Log Message:
  -----------
  [AMDGPU] Set the default globals address space to 1

This will ensure that passes that add new global variables will create them
in address space 1 once the passes have been updated to no longer default
to the implicit address space zero.
This also changes AutoUpgrade.cpp to add -G1 to the DataLayout if it wasn't
already to present to ensure bitcode backwards compatibility.

Reviewed by: arsenm

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


Compare: https://github.com/llvm/llvm-project/compare/4766a86cf2f9...51e09e1d5aa4