[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