[all-commits] [llvm/llvm-project] d5c049: [openmp] Fix 51647, corrupt bitcode on amdgpu

dpalermo via All-commits all-commits at lists.llvm.org
Mon Sep 13 07:25:05 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d5c049a3f68791490e8c87d9974e9831ede0ada0
      https://github.com/llvm/llvm-project/commit/d5c049a3f68791490e8c87d9974e9831ede0ada0
  Author: dpalermo <Dan.Palermo at amd.com>
  Date:   2021-09-13 (Mon, 13 Sep 2021)

  Changed paths:
    M llvm/lib/Transforms/IPO/OpenMPOpt.cpp
    M llvm/test/Transforms/OpenMP/custom_state_machines.ll
    M llvm/test/Transforms/OpenMP/spmdization.ll

  Log Message:
  -----------
  [openmp] Fix 51647, corrupt bitcode on amdgpu

Patch by @dpalermo

The corrupt bitcode reported in https://bugs.llvm.org/show_bug.cgi?id=51647 seems to be a result of a later pass changing the workfn variable to addrspace(5) (thread private, on the stack). That seems reasonable for an alloca without an address space so it's an open question why that can crash the bitcode reader.

This change puts it in the thread private address space to begin with which means whatever misfired further down the pipeline does not break it. That matches the codegen from clang where stack variables are always annotated (5) and then addrspace cast prior to following use.

This therefore patches around whatever unsuccessfully moved the alloca variable to addrspace(5). That solves the problem of openmp opt producing code that crashes the bitcode reader. It should be possible to create a minimal repro for the underlying bug based on some handwritten IR that uses an alloca in a generic address space.

Reviewed By: ronlieb, jdoerfert, dpalermo-phab

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




More information about the All-commits mailing list