[all-commits] [llvm/llvm-project] 67a290: [VectorCombine] Insert addrspacecast when crossing...

[Fraser Cormack via All-commits]

  Branch: refs/heads/release/14.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 67a290460c374d5e0d18a06c798896cac0b19e59
      https://github.com/llvm/llvm-project/commit/67a290460c374d5e0d18a06c798896cac0b19e59
  Author: Fraser Cormack <fraser at codeplay.com>
  Date:   2022-04-06 (Wed, 06 Apr 2022)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/VectorCombine.cpp
    M llvm/test/Transforms/VectorCombine/AMDGPU/as-transition-inseltpoison.ll
    M llvm/test/Transforms/VectorCombine/AMDGPU/as-transition.ll
    M llvm/test/Transforms/VectorCombine/X86/load-inseltpoison.ll

  Log Message:
  -----------
  [VectorCombine] Insert addrspacecast when crossing address space boundaries

We can not bitcast pointers across different address spaces. This was
previously fixed in D89577 but then in D93229 an enhancement was added
which peeks further through the ponter operand, opening up the
possibility that address-space violations could be introduced.

Instead of bailing as the previous fix did, simply insert an
addrspacecast cast instruction.

Reviewed By: lebedev.ri

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

(cherry picked from commit 2e44b7872bc638ed884ae4aa86e38b3b47e0b65a)


  Commit: d53e2603383a1304c3ee081169b1bf8dac93f8e4
      https://github.com/llvm/llvm-project/commit/d53e2603383a1304c3ee081169b1bf8dac93f8e4
  Author: Fangrui Song <i at maskray.me>
  Date:   2022-04-06 (Wed, 06 Apr 2022)

  Changed paths:
    M llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
    M llvm/lib/Target/AArch64/MCTargetDesc/AArch64ELFStreamer.cpp
    M llvm/test/MC/AArch64/directive-variant_pcs-err.s
    M llvm/test/MC/AArch64/directive-variant_pcs.s

  Log Message:
  -----------
  [AArch64] Allow .variant_pcs before the symbol is registered

glibc sysdeps/aarch64/tst-vpcs-mod.S has something like:
```
.variant_pcs    vpcs_call
.global vpcs_call
```

This is supported by GNU as but leads to an error in MC. Use getOrCreateSymbol
to support a not-yet-registered symbol: call `registerSymbol` to ensure the
symbol exists even if there is no binding directive/label, to match GNU as.

While here, improve tests to check (1) a local symbol can get
STO_AARCH64_VARIANT_PCS (2) undefined .variant_pcs (3) an alias does not
inherit STO_AARCH64_VARIANT_PCS.

Reviewed By: efriedma

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

(cherry picked from commit cfbd5c8e4aa1ba3fc11fb408eeedbb05bd235956)


  Commit: fd98b0f1a6a1c57bd368c78c7cf86fc9f527d452
      https://github.com/llvm/llvm-project/commit/fd98b0f1a6a1c57bd368c78c7cf86fc9f527d452
  Author: Fraser Cormack <fraser at codeplay.com>
  Date:   2022-04-06 (Wed, 06 Apr 2022)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
    A llvm/test/CodeGen/RISCV/rvv/constant-folding-crash.ll

  Log Message:
  -----------
  [SelectionDAG] Don't create illegally-typed nodes while constant folding

This patch fixes a (seemingly very rare) crash during vector constant
folding introduced in D113300.

Normally, during legalization, if we create an illegally-typed node during
a failed attempt at constant folding it's cleaned up before being
visited, due to it having no uses.

If, however, an illegally-typed node is created during one round of
legalization and isn't cleaned up, it's possible for a second round of
legalization to create new illegally-typed nodes which add extra uses to
the old illegal nodes. This means that we can end up visiting the old
nodes before they're known to be dead, at which point we crash.

I'm not happy about this fix. Creating illegal types at all seems like a
bad idea, but we all-too-often rely on illegal constants being
successfully folded and being fixed up afterwards. However, we can't
rely on constant folding actually happening, and we don't have a
foolproof way of peering into the future.

Perhaps the correct fix is to revisit the node-iteration order during
legalization, ensuring we visit all uses of nodes before the nodes
themselves. Or alternatively we could try and clean up dead nodes
immediately after failing constant folding.

Reviewed By: RKSimon

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

(cherry picked from commit 43a91a8474f55241404199f6b8798ac6467c2687)


Compare: https://github.com/llvm/llvm-project/compare/353068233f21...fd98b0f1a6a1