User Details
- User Since
- Dec 3 2015, 1:10 AM (268 w, 3 d)
Fri, Jan 22
Great, then I'm slightly less puzzled :) Thanks!
Thanks for fixing this!
I don't know this code at all, but I'm puzzled by this sentence in the summary:
The path for.body -> cond.false -> cond.end should be taken when 'select i1 true, i1 poison, i1 false' holds
Thu, Jan 21
I wrote a PR about this:
https://bugs.llvm.org/show_bug.cgi?id=48832
I've been able to reproduce the problem I see for an in-tree architecture.
So with
opt -mtriple=s390x-unknown-linux -mcpu=z13 -loop-vectorize -S -o - bbi-51947.ll
I get
store <4 x i32> poison, <4 x i32>* %6, align 1
but before this patch I got
store <4 x i32> zeroinitializer, <4 x i32>* %6, align 1
The input is
%arrayt = type [64 x i32]
Wed, Jan 20
I'm not sure what happens yet, but with this patch I'm seeing a miscompile.
Diffs start occuring after the loop vectorizer. Previously we got this store
store <4 x i32> zeroinitializer, <4 x i32>* %8, align 1, !dbg !16
but now we instead get this:
store <4 x i32> poison, <4 x i32>* %8, align 1, !dbg !16
Are you aware of any problems?
I'll submit this for @ehjogab in a little bit.
Thu, Jan 7
Tue, Jan 5
I see a failed assertion with this patch if I run
opt -o /dev/null bbi-51466.ll -simplifycfg
on the input
I pushed this for @ehjogab
Mon, Jan 4
Wed, Dec 30
I've seen a miscompile for my OOT target with this patch. Unfortunately I haven't gone to the bottom with it yet (and I don't think I will until after new years), so I'm not sure what the problem is exactly, but I think that AA comes to the conclusion that a read and a write to the exact same location doesn't alias, and then things go wrong. Are you aware of any problems?
Tue, Dec 29
I'm still seeing a case where instcombine hangs after d9ebaeeb468 "[InstCombine] Hoist xor-by-constant from xor-by-value", even with this fix.
Mon, Dec 28
The following starts failing with this commit:
opt -S -o /dev/null bbi-51071.ll -early-cse
With bbi-51071.ll being
@f.a = external global i16, align 1
I submitted this for @ehjogab
I submitted this for @ehjogab
Dec 10 2020
We've noticed a crash that started occuring with this patch.
Running
Nov 30 2020
I'm seeing a miscompile with this patch. I'm not very good at the semantic differences between undef and poison so I don't know really where it goes wrong.
Nov 26 2020
Another little ping.
Nov 23 2020
I submitted this for @ehjogab
Nov 19 2020
Do the easiest fix.
Nov 18 2020
Nov 17 2020
The following hits an assertion with this patch. If I run
opt -S -o - aa.ll -aa-eval
Thanks!
Nov 16 2020
Hi!
This seems to fail if one of the predecessors to the PHI block is dead and contain weird stuff e.g. like this:
define void @foo() { bb.0: br label %bb.1
Nov 12 2020
Thanks! The problem I saw is fixed with this patch.
Nov 11 2020
I hit an assertion with this patch:
opt: ../lib/IR/Type.cpp:620: static llvm::FixedVectorType *llvm::FixedVectorType::get(llvm::Type *, unsigned int): Assertion `isValidElementType(ElementType) && "Element type of a VectorType must " "be an integer, floating point, or " "pointer type."' failed.
Nov 4 2020
I found a new problem after this was turned on again in 51ff04567b2f.
With
opt -S -o - bbi-49235.ll -memoryssa -gvn -dse -verify-memoryssa
I hit
opt: ../lib/Analysis/MemorySSA.cpp:2063: void llvm::MemorySSA::verifyOrderingDominationAndDefUses(llvm::Function &) const: Assertion `&*ALI == *AAI && "Not the same accesses in the same order"' failed.
with bbi-49235.ll being
define void @k() { entry: %tobool = icmp ne i16 1, 0 %0 = xor i1 %tobool, true call void @llvm.assume(i1 %0) call void @f() ret void }
Bah, I meant to post my comment in https://reviews.llvm.org/D89613. I did now.
Is this commit supposed to change the output from llc?
Is this commit supposed to change the output from llc?
Nov 3 2020
Changed names of the testcase functions and changed to zext in visitPtrToInt.
Nov 2 2020
Oct 28 2020
We got similar problems for our downstream target. We worked around that by bailing out early in PragmaSTDC_FENV_ACCESSHandler::HandlePragma for our target but perhaps one could check hasStrictFP() instead and ignore the pragma if that is false?
Oct 26 2020
Are there any outstanding issues left or is this perhaps good enough to be submitted?
Oct 23 2020
I don't know what the best fix is, but I've verified that this patch solves the problem I saw and I haven't seen anything weird pop up with the patch in some limited testing I've done with it.
Thanks!
Oct 22 2020
https://bugs.llvm.org/show_bug.cgi?id=47945 started happening with this patch.
Oct 16 2020
Oct 14 2020
Oct 13 2020
I got my share of doom too, even after the fix.
So
opt -S -o - bbi-48445.ll -indvars
crashes with
opt: ../lib/IR/Constants.cpp:1896: static llvm::Constant *llvm::ConstantExpr::getZExt(llvm::Constant *, llvm::Type *, bool): Assertion `C->getType()->isIntOrIntVectorTy() && "ZEXt operand must be integral"' failed.
for the following input:
Oct 7 2020
I just wrote
https://bugs.llvm.org/show_bug.cgi?id=47753
about a failure that starts occuring with this patch.
Oct 6 2020
Oct 5 2020
I submitted for ehjogab.
Oct 1 2020
Hi!
I don't understand why, but with this commit I start seeing several warnings like this when compiling builtins:
Sep 30 2020
I submited this for ehjogab
Sep 24 2020
Sep 18 2020
We've run into a case where instcombine crashes with this patch:
opt -o /dev/null bbi-47401.ll -instcombine
on
@c = external global i16*, align 1
Sep 17 2020
Sep 14 2020
I wrote https://bugs.llvm.org/show_bug.cgi?id=47517 about a crash that starts happening with this patch.
I'm seeing what I think is a miscompile with this:
opt -S -dse -o - dse.ll
on
Sep 7 2020
Sep 4 2020
The following crashes for me with this patch
opt -memoryssa -gvn -early-cse-memssa -S -o - foo.ll
Sep 3 2020
Sep 2 2020
We ran into problems with this commit.
Sep 1 2020
I wrote
https://bugs.llvm.org/show_bug.cgi?id=47381
about a similar problem also caused by the missing setting of Changed in SimplifyIndvar::eliminateOverflowIntrinsic.
Aug 28 2020
We ran into a problem with this patch. I wrote https://bugs.llvm.org/show_bug.cgi?id=47343 about it.
Aug 26 2020
We've run with changes like this for a long time to make the routines work for our out of tree target where int is also 16 bits so thumbs up from me even if I'm not sure I can formally LGTM it.