[PATCH] D126689: [IR] Enable opaque pointers by default

uabelho added a comment. In D126689#4654126 , @nikic wrote: > In D126689#4654124 , @uabelho wrote: > >> @nikic: Thanks, nothing to do there then even if I'm surprised. >> >> I'm not sure but I *think* that llvm-re

[PATCH] D126689: [IR] Enable opaque pointers by default

nikic added a comment. In D126689#4654124 , @uabelho wrote: > @nikic: Thanks, nothing to do there then even if I'm surprised. > > I'm not sure but I *think* that llvm-reduce may have some problems with this. > For my out of tree target I recently saw a c

[PATCH] D126689: [IR] Enable opaque pointers by default

uabelho added a comment. @nikic: Thanks, nothing to do there then even if I'm surprised. I'm not sure but I *think* that llvm-reduce may have some problems with this. For my out of tree target I recently saw a case where llvm-reduced crashed with llvm-reduce: ../tools/llvm-reduce/deltas/Reduc

[PATCH] D126689: [IR] Enable opaque pointers by default

nikic added a comment. @uabelho The call is well-defined from an LLVM IR perspective, so the verifier cannot reject it, just as it can't reject calling convention or ABI attribute mismatch. In this specific case, the call is likely undefined behavior, but that is not generally the case just bec

[PATCH] D126689: [IR] Enable opaque pointers by default

uabelho added a comment. Herald added subscribers: gysit, Dinistro, bviyer, jplehr, Moerafaat, kmitropoulou, zero9178, StephenFan. Herald added a reviewer: dcaballe. Hi @nikic, I know I'm very late to the party with this, but I just noticed that since opaque pointers got turned on by default, t

[PATCH] D126689: [IR] Enable opaque pointers by default

uabelho added a comment. In D126689#3553292 , @nikic wrote: > @uabelho Here's a slightly cleaned up test case that does not use opaque > pointers: > > target triple = "x86_64-unknown-linux-gnu" > > define void @test(i1 %cond, <1 x i16>* %p) { >

[PATCH] D126689: [IR] Enable opaque pointers by default

aprantl added a comment. I was able to update LLDB https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/44252/. We can leave this in. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126689/new/ https://reviews.llvm.org/D126689 ___

[PATCH] D126689: [IR] Enable opaque pointers by default

aprantl added a comment. It looks like this patch has broken 168 tests in LLDB: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/44239/changes#41d5033eb162cb92b684855166cabfa3983b74c6 I'm going to dig a little deeper, but I might ask you to revert this until we can figure out a solution

[PATCH] D126689: [IR] Enable opaque pointers by default

nikic added a comment. I believe https://reviews.llvm.org/D126886 should fix the DAGCombiner issue. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126689/new/ https://reviews.llvm.org/D126689 ___ cfe-comm

[PATCH] D126689: [IR] Enable opaque pointers by default

nikic added a comment. @uabelho Here's a slightly cleaned up test case that does not use opaque pointers: target triple = "x86_64-unknown-linux-gnu" define void @test(i1 %cond, <1 x i16>* %p) { br label %loop loop: %v = load <1 x i16>, <1 x i16>* %p, align 2 %ins = insert

[PATCH] D126689: [IR] Enable opaque pointers by default

uabelho added a comment. Is anyone here ever using llvm-stress? I noticed that with this patch, llvm-stress seems to start producing code that llc crashes on, and it crashes even if I run on older llc versions. One example: llc -o /dev/null stress.ll crashes with llc: ../lib/CodeGen/Select