[all-commits] [llvm/llvm-project] 9e02e8: fix producing multiple identical opaque pointer ty...

[Vyacheslav Levytskyy via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9e02e8f1a76693f001c7f52ffddd92c492a2254e
      https://github.com/llvm/llvm-project/commit/9e02e8f1a76693f001c7f52ffddd92c492a2254e
  Author: Vyacheslav Levytskyy <89994100+VyacheslavLevytskyy at users.noreply.github.com>
  Date:   2024-01-30 (Tue, 30 Jan 2024)

  Changed paths:
    M llvm/lib/Target/SPIRV/SPIRVGlobalRegistry.cpp
    M llvm/test/CodeGen/SPIRV/opencl/device_execution/execute_block.ll
    A llvm/test/CodeGen/SPIRV/pointers/struct-opaque-pointers.ll

  Log Message:
  -----------
  fix producing multiple identical opaque pointer types (#79060)

This PR fixes https://github.com/llvm/llvm-project/issues/79057 and
improves code generation for opaque pointers by replacing the culprit
SPIRVGlobalRegistry::getOpTypePointer() call with a more appropriate
SPIRVGlobalRegistry::getOrCreateSPIRVPointerType() call. The latter
function works together with the `DuplicatesTracker`
(`SPIRVGeneralDuplicatesTracker DT;` from `class SPIRVGlobalRegistry`)
to trace existence of previous definitions of opaque pointers. This
allows to produce just one `OpTypePointer` command for all identical
opaque pointers definitions and to return the very same type record for
subsequent `SPIRVGlobalRegistry::createSPIRVType()` invocations.

This PR alone improves code generation by producing a single needed
definition per all opaque pointers to i8 of the same address space
instead of multiple identical definitions produced before the patch.
>From the root cause analysis of
https://github.com/llvm/llvm-project/issues/79057 we see also that this
PR resolves the problem of inconsistency between keeping multiple
instruction for identical opaque pointer types and just a single record
for all such instructions in the `DuplicatesTracker`, and so it also
resolves the issue with crashes on creation of a struct with opaque
pointer fields due to the fact that now such struct fields refer to the
same operand `<id>` having a required record in the data structure used
for dependencies analysis (see
https://github.com/llvm/llvm-project/issues/79057).