Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

LLVM Crash in SelectionDAG #36955

Closed
Keno opened this issue Aug 7, 2020 · 3 comments
Closed

LLVM Crash in SelectionDAG #36955

Keno opened this issue Aug 7, 2020 · 3 comments
Labels
bug Indicates an unexpected problem or unintended behavior compiler:codegen Generation of LLVM IR and native code rr trace included upstream The issue is with an upstream dependency, e.g. LLVM

Comments

@Keno
Copy link
Member

Keno commented Aug 7, 2020

Over in https://github.com/PumasAI/PumasTutorials.jl/pull/56, @chriselrod reports an LLVM crash in SelectionDAG with the following backtrace:

julia> pop = read_nca(data, llq=0concu, timeu=timeu, concu=concu, amtu=amtu)

signal (11): Segmentation fault
in expression starting at REPL[128]:1
isVectorTy at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/include/llvm/IR/Type.h:229 [inlined]
isExtendedVector at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/ValueTypes.cpp:59
isVector at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/include/llvm/CodeGen/ValueTypes.h:151 [inlined]
getScalarType at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/include/llvm/CodeGen/ValueTypes.h:260
getScalarSizeInBits at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/include/llvm/CodeGen/ValueTypes.h:298 [inlined]
SimplifyDemandedBits at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/TargetLowering.cpp:1569
SimplifyDemandedBits at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/TargetLowering.cpp:863
SimplifyDemandedBits at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1225 [inlined]
SimplifyDemandedBits at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:300 [inlined]
SimplifyDemandedBits at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:293
visitOR at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:5891
combine at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1801
Run at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1625 [inlined]
Combine at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:20876
CodeGenAndEmitDAG at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:817
SelectAllBasicBlocks at /home/chriselrod/Documents/languages/juliarelease/deps/srccache/llvm-9.0.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1588
@Keno Keno added bug Indicates an unexpected problem or unintended behavior compiler:codegen Generation of LLVM IR and native code labels Aug 7, 2020
@Keno
Copy link
Member Author

Keno commented Aug 7, 2020

Automated reduction from the included rr trace:

; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "cleanblq##kw"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128-ni:10:11:12:13"
target triple = "x86_64-unknown-linux-gnu"

define void @"julia_cleanblq##kw_5182"() #0 {
pass:                                             ; preds = %top
  %0 = fcmp une double 0.000000e+00, 0x43E0000000000000
  %1 = icmp eq i64 0, 0
  %broadcast.splatinsert3240 = insertelement <8 x i1> undef, i1 %0, i32 0
  %broadcast.splat3241 = shufflevector <8 x i1> %broadcast.splatinsert3240, <8 x i1> undef, <8 x i32> zeroinitializer
  %broadcast.splatinsert3242 = insertelement <8 x i1> undef, i1 %1, i32 0
  %broadcast.splat3243 = shufflevector <8 x i1> %broadcast.splatinsert3242, <8 x i1> undef, <8 x i32> zeroinitializer
  %2 = insertelement <8 x double> undef, double 0.000000e+00, i32 7
  %wide.load3235 = load <8 x double>, <8 x double> addrspace(13)* undef, align 8
  %3 = fcmp ugt <8 x double> %wide.load3235, zeroinitializer
  %4 = fcmp olt <8 x double> %2, zeroinitializer
  %5 = fcmp oeq <8 x double> %2, zeroinitializer
  %6 = and <8 x i1> %5, %broadcast.splat3241
  %7 = and <8 x i1> %6, %broadcast.splat3243
  %8 = xor <8 x i1> %3, <i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true>
  %9 = and <8 x i1> %4, %8
  %predphi3244 = select <8 x i1> %3, <8 x i1> zeroinitializer, <8 x i1> %7
  %predphi3245 = select <8 x i1> %9, <8 x i1> <i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true>, <8 x i1> %predphi3244
  %10 = zext <8 x i1> %predphi3245 to <8 x i8>
  store <8 x i8> %10, <8 x i8> addrspace(13)* undef, align 1
  ret void
}

attributes #0 = { "target-cpu"="skylake-avx512" }

!llvm.module.flags = !{!0}

!0 = !{i32 1, !"Debug Info Version", i32 3}

@Keno Keno added the upstream The issue is with an upstream dependency, e.g. LLVM label Aug 7, 2020
@Keno
Copy link
Member Author

Keno commented Aug 7, 2020

Proposed upstream fix: https://reviews.llvm.org/D85499

Keno added a commit that referenced this issue Aug 7, 2020
@Keno
Fix #36955
4feaf3f 
This is an LLVM bug. See upstream discussion at https://reviews.llvm.org/D85499.
Keno added a commit that referenced this issue Aug 7, 2020
@Keno
Fix #36955
f629c80 
This is an LLVM bug. See upstream discussion at https://reviews.llvm.org/D85499.
@Keno Keno reopened this Aug 8, 2020
@Keno
Copy link
Member Author

Keno commented Aug 8, 2020

Fixed upstream, but we still need to bump it here.

Keno added a commit that referenced this issue Aug 8, 2020
@Keno
Fix #36955
bcd56a4 
This is an LLVM bug. See upstream discussion at https://reviews.llvm.org/D85499.
@Keno Keno closed this as completed in 91d384c Aug 8, 2020
@KristofferC KristofferC mentioned this issue Aug 10, 2020
Merged
25 tasks
KristofferC pushed a commit that referenced this issue Aug 10, 2020
@Keno @KristofferC
Fix #36955 (#36956)
e6b2a56 
This is an LLVM bug. See upstream discussion at https://reviews.llvm.org/D85499.

(cherry picked from commit 91d384c)
simeonschaub pushed a commit to simeonschaub/julia that referenced this issue Aug 11, 2020
@Keno @simeonschaub
Fix JuliaLang#36955 (JuliaLang#36956)
8e9dda2 
This is an LLVM bug. See upstream discussion at https://reviews.llvm.org/D85499.
KristofferC pushed a commit that referenced this issue Aug 18, 2020
@Keno @KristofferC
Fix #36955 (#36956)
e4756e0 
This is an LLVM bug. See upstream discussion at https://reviews.llvm.org/D85499.

(cherry picked from commit 91d384c)
KristofferC pushed a commit that referenced this issue Aug 19, 2020
@Keno @KristofferC
Fix #36955 (#36956)
9477413 
This is an LLVM bug. See upstream discussion at https://reviews.llvm.org/D85499.

(cherry picked from commit 91d384c)
github-actions bot pushed a commit to tstellar/llvm-project that referenced this issue Nov 24, 2020
@Keno @llvmbot
[X86] Don't produce bad x86andp nodes for i1 vectors
76ebc79 
In D85499, I attempted to fix this same issue by canonicalizing
andnp for i1 vectors, but since there was some opposition to such
a change, this commit just fixes the bug by using two different
forms depending on which kind of vector type is in use. We can
then always decide to switch the canonical forms later.

Description of the original bug:
We have a DAG combine that tries to fold (vselect cond, 0000..., X) -> (andnp cond, x).
However, it does so by attempting to create an i64 vector with the number
of elements obtained by truncating division by 64 from the bitwidth. This is
bad for mask vectors like v8i1, since that division is just zero. Besides,
we don't want i64 vectors anyway. For i1 vectors, switch the pattern
to (andnp (not cond), x), which is the canonical form for `kandn`
on mask registers.

Fixes JuliaLang/julia#36955.

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

(cherry picked from commit c58674d)
github-actions bot pushed a commit to tstellar/llvm-project that referenced this issue Nov 24, 2020
@Keno @llvmbot
[X86] Don't produce bad x86andp nodes for i1 vectors
8f8de14 
In D85499, I attempted to fix this same issue by canonicalizing
andnp for i1 vectors, but since there was some opposition to such
a change, this commit just fixes the bug by using two different
forms depending on which kind of vector type is in use. We can
then always decide to switch the canonical forms later.

Description of the original bug:
We have a DAG combine that tries to fold (vselect cond, 0000..., X) -> (andnp cond, x).
However, it does so by attempting to create an i64 vector with the number
of elements obtained by truncating division by 64 from the bitwidth. This is
bad for mask vectors like v8i1, since that division is just zero. Besides,
we don't want i64 vectors anyway. For i1 vectors, switch the pattern
to (andnp (not cond), x), which is the canonical form for `kandn`
on mask registers.

Fixes JuliaLang/julia#36955.

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

(cherry picked from commit c58674d)
tstellar pushed a commit to tstellar/llvm-project that referenced this issue Nov 25, 2020
@Keno @tstellar
[X86] Don't produce bad x86andp nodes for i1 vectors
3e8d980 
In D85499, I attempted to fix this same issue by canonicalizing
andnp for i1 vectors, but since there was some opposition to such
a change, this commit just fixes the bug by using two different
forms depending on which kind of vector type is in use. We can
then always decide to switch the canonical forms later.

Description of the original bug:
We have a DAG combine that tries to fold (vselect cond, 0000..., X) -> (andnp cond, x).
However, it does so by attempting to create an i64 vector with the number
of elements obtained by truncating division by 64 from the bitwidth. This is
bad for mask vectors like v8i1, since that division is just zero. Besides,
we don't want i64 vectors anyway. For i1 vectors, switch the pattern
to (andnp (not cond), x), which is the canonical form for `kandn`
on mask registers.

Fixes JuliaLang/julia#36955.

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

(cherry picked from commit c58674d)
arichardson pushed a commit to arichardson/llvm-project that referenced this issue Mar 22, 2021
@Keno @arichardson
[X86] Don't produce bad x86andp nodes for i1 vectors
0e8e821 
In D85499, I attempted to fix this same issue by canonicalizing
andnp for i1 vectors, but since there was some opposition to such
a change, this commit just fixes the bug by using two different
forms depending on which kind of vector type is in use. We can
then always decide to switch the canonical forms later.

Description of the original bug:
We have a DAG combine that tries to fold (vselect cond, 0000..., X) -> (andnp cond, x).
However, it does so by attempting to create an i64 vector with the number
of elements obtained by truncating division by 64 from the bitwidth. This is
bad for mask vectors like v8i1, since that division is just zero. Besides,
we don't want i64 vectors anyway. For i1 vectors, switch the pattern
to (andnp (not cond), x), which is the canonical form for `kandn`
on mask registers.

Fixes JuliaLang/julia#36955.

Differential Revision: https://reviews.llvm.org/D85553
ajohnson-uoregon pushed a commit to ajohnson-uoregon/clang-rewrite-only that referenced this issue Jul 17, 2022
@Keno @tstellar
[X86] Don't produce bad x86andp nodes for i1 vectors
08cebf2 
In D85499, I attempted to fix this same issue by canonicalizing
andnp for i1 vectors, but since there was some opposition to such
a change, this commit just fixes the bug by using two different
forms depending on which kind of vector type is in use. We can
then always decide to switch the canonical forms later.

Description of the original bug:
We have a DAG combine that tries to fold (vselect cond, 0000..., X) -> (andnp cond, x).
However, it does so by attempting to create an i64 vector with the number
of elements obtained by truncating division by 64 from the bitwidth. This is
bad for mask vectors like v8i1, since that division is just zero. Besides,
we don't want i64 vectors anyway. For i1 vectors, switch the pattern
to (andnp (not cond), x), which is the canonical form for `kandn`
on mask registers.

Fixes JuliaLang/julia#36955.

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

(cherry picked from commit 1758305)
mem-frob pushed a commit to draperlaboratory/hope-llvm-project that referenced this issue Oct 7, 2022
@Keno
[X86] Don't produce bad x86andp nodes for i1 vectors
27ba213 
In D85499, I attempted to fix this same issue by canonicalizing
andnp for i1 vectors, but since there was some opposition to such
a change, this commit just fixes the bug by using two different
forms depending on which kind of vector type is in use. We can
then always decide to switch the canonical forms later.

Description of the original bug:
We have a DAG combine that tries to fold (vselect cond, 0000..., X) -> (andnp cond, x).
However, it does so by attempting to create an i64 vector with the number
of elements obtained by truncating division by 64 from the bitwidth. This is
bad for mask vectors like v8i1, since that division is just zero. Besides,
we don't want i64 vectors anyway. For i1 vectors, switch the pattern
to (andnp (not cond), x), which is the canonical form for `kandn`
on mask registers.

Fixes JuliaLang/julia#36955.

Differential Revision: https://reviews.llvm.org/D85553
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Indicates an unexpected problem or unintended behavior compiler:codegen Generation of LLVM IR and native code rr trace included upstream The issue is with an upstream dependency, e.g. LLVM
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Keno