@@ -6397,6 +6397,48 @@ static Value *simplifyBinaryIntrinsic(Function *F, Value
*Op0, Value *Op1,
return Constant::getNullValue(ReturnType);
break;
}
+ case Intrinsic::ptrmask: {
+// Fail loudly in case this is ever changed.
+// TODO: If vector types are
nikic wrote:
> See most recent comments about missing tests. That being said code looks
> functionally correct to me. Still not 100% sure this is a desirable change.
> Will defer to @nikic about that.
I'm also skeptical about accepting this optimization. Looking at the motivating
case in
https://github.com/nikic commented:
I think most of the comments from the ctpop review also apply to this one.
https://github.com/llvm/llvm-project/pull/67917
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/nikic commented:
I think most of the comments from the ctpop review also apply to this one.
https://github.com/llvm/llvm-project/pull/67917
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/69589
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
> @nikic Sorry for the mess :/
>
> I took the `target=` approach from
> [here](https://llvm.org/docs/TestingGuide.html#constraining-test-execution).
> Following the current buildbot status, this also does not seem to crash. Does
> this mean the rests are still incorrect and are
nikic wrote:
The correct check is `REQUIRES: aarch64-registered-target`, not `REQUIRES:
target=aarch64`.
https://github.com/llvm/llvm-project/pull/69582
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
nikic wrote:
> > We should update LangRef and require that the integer arg has the size of
> > the pointer index type
>
> As in disallow say `ptrmask.p0.i32` on typical systems with 64-bit pointer
> index? (So a lot of the current usages). Or something else?
Yes, exactly. I've started
nikic wrote:
We should update LangRef and require that the integer arg has the size of the
pointer index type (with current GEP semantics implying a 1-extend to pointer
type width), implement a Verifier check for that, and add an assert in SDAG
lowering that the index type size is the pointer
@@ -3083,6 +3083,19 @@ ScalarExprEmitter::VisitUnaryExprOrTypeTraitExpr(
E->getTypeOfArgument()->getPointeeType()))
.getQuantity();
return llvm::ConstantInt::get(CGF.SizeTy, Alignment);
+ } else if (E->getKind() == UETT_VectorElements) {
+
@@ -3083,6 +3083,19 @@ ScalarExprEmitter::VisitUnaryExprOrTypeTraitExpr(
E->getTypeOfArgument()->getPointeeType()))
.getQuantity();
return llvm::ConstantInt::get(CGF.SizeTy, Alignment);
+ } else if (E->getKind() == UETT_VectorElements) {
+
@@ -3083,6 +3083,19 @@ ScalarExprEmitter::VisitUnaryExprOrTypeTraitExpr(
E->getTypeOfArgument()->getPointeeType()))
.getQuantity();
return llvm::ConstantInt::get(CGF.SizeTy, Alignment);
+ } else if (E->getKind() == UETT_VectorElements) {
+
nikic wrote:
You probably should just use find_program instead of llvm_find_program. It
looks like llvm_find_program is used in just a single place, while we have very
wide direct use of find_program, so I'm not sure why it is a thing in the first
place.
Author: Nikita Popov
Date: 2023-10-13T09:39:00+02:00
New Revision: ac32d7b87f4d4b546eea96b9b722e88fdb3a5b49
URL:
https://github.com/llvm/llvm-project/commit/ac32d7b87f4d4b546eea96b9b722e88fdb3a5b49
DIFF:
https://github.com/llvm/llvm-project/commit/ac32d7b87f4d4b546eea96b9b722e88fdb3a5b49.diff
nikic wrote:
Actually no, that's not possible as config-ix modules are explicitly private to
their subproject and should not be used outside them. I'm going to revert this
change due to this layering violation.
https://github.com/llvm/llvm-project/pull/65650
nikic wrote:
This also breaks the clang standalone build. You need to `include(config-ix)`
in order to use `llvm_find_program`.
https://github.com/llvm/llvm-project/pull/65650
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -6,15 +6,16 @@ target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:32-f3
define ptr@test1(ptr %A, i32 %Offset) {
; CHECK-LABEL: @test1(
; CHECK-NEXT: entry:
+; CHECK-NEXT:[[TMP:%.*]] = getelementptr inbounds i32, ptr [[A:%.*]], i32
@@ -637,9 +637,8 @@ define ptr @select_of_gep(i1 %c, ptr %p) {
define ptr @select_of_gep_different_type(i1 %c, ptr %p) {
; CHECK-LABEL: @select_of_gep_different_type(
-; CHECK-NEXT:[[GEP1:%.*]] = getelementptr i32, ptr [[P:%.*]], i64 1
-; CHECK-NEXT:[[GEP2:%.*]] =
@@ -597,14 +598,13 @@ define ptr @gep_of_phi_of_gep_different_type(i1 %c, ptr
%p) {
; CHECK-LABEL: @gep_of_phi_of_gep_different_type(
; CHECK-NEXT:br i1 [[C:%.*]], label [[IF:%.*]], label [[ELSE:%.*]]
; CHECK: if:
-; CHECK-NEXT:[[GEP1:%.*]] = getelementptr i32,
https://github.com/nikic commented:
I looked through the test diffs, and it seems like the only substantial
regressions are all related to the indexed compare fold, which should be made
type-independent.
https://github.com/llvm/llvm-project/pull/68882
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/68882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3,8 +3,9 @@
define ptr @f1(ptr %arg, i64 %arg1) {
; CHECK-LABEL: @f1(
-; CHECK-NEXT:[[TMP1:%.*]] = getelementptr [6 x i32], ptr [[ARG:%.*]], i64
3, i64 [[ARG1:%.*]]
-; CHECK-NEXT:ret ptr [[TMP1]]
+; CHECK-NEXT:[[TMP1:%.*]] = getelementptr i8, ptr [[ARG:%.*]],
@@ -560,14 +560,15 @@ define i32 @test28() nounwind {
; CHECK-NEXT: entry:
; CHECK-NEXT:[[ORIENTATIONS:%.*]] = alloca [1 x [1 x %struct.x]], align 8
; CHECK-NEXT:[[T3:%.*]] = call i32 @puts(ptr noundef nonnull
dereferenceable(1) @.str) #[[ATTR0]]
+; CHECK-NEXT:
Author: Nikita Popov
Date: 2023-10-12T14:24:26+02:00
New Revision: e44c9fd197a2209b6b7b266fb0a381ee8fcec12b
URL:
https://github.com/llvm/llvm-project/commit/e44c9fd197a2209b6b7b266fb0a381ee8fcec12b
DIFF:
https://github.com/llvm/llvm-project/commit/e44c9fd197a2209b6b7b266fb0a381ee8fcec12b.diff
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/67915
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/67915
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
> GVN seems to have different behavior regarding LoopInfo in the LegacyPM and
> NewPM, but that's an orthogonal issue. I'll check whether always requiring
> LoopInfo in GVN has any compile-time impact, as I don't think this is
> supposed to be an optional analysis there
nikic wrote:
Using the term for MIR is okay, because it does not have a pre-existing notion
of canonical form. Doing the same for IR is not okay, because it already has a
canonical form and this pass does not produce it. Calling this `ir-normalizer`
instead of `ir-canonicalizer` should convey
nikic wrote:
Using the term for MIR is okay, because it does not have a pre-existing notion
of canonical form. Doing the same for IR is not okay, because it already has a
canonical form and this pass does not produce it. Calling this `ir-normalizer`
instead of `ir-canonicalizer` should convey
https://github.com/nikic approved this pull request.
Yeah, it looks correct now.
https://github.com/llvm/llvm-project/pull/65852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic approved this pull request.
Yeah, it looks correct now.
https://github.com/llvm/llvm-project/pull/65852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
Looks like incorrect conflict resolution in the last merge.
https://github.com/llvm/llvm-project/pull/65852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
Looks like incorrect conflict resolution in the last merge.
https://github.com/llvm/llvm-project/pull/65852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
Can you please pre-commit the new tests as well (and double-check that there is
no unexpected operand order canonicalization while doing that)?
https://github.com/llvm/llvm-project/pull/67915
___
cfe-commits mailing list
https://github.com/nikic commented:
Seems like some test coverage is missing here?
* Commuted add
* Commuted sub (negative test)
* Commuted and
* Multi-use add (negative test)
https://github.com/llvm/llvm-project/pull/67915
___
cfe-commits mailing
https://github.com/nikic approved this pull request.
Basically LGTM, but I think this is still missing negative tests for
non-equality pred1/pred2?
https://github.com/llvm/llvm-project/pull/65852
___
cfe-commits mailing list
https://github.com/nikic approved this pull request.
Basically LGTM, but I think this is still missing negative tests for
non-equality pred1/pred2?
https://github.com/llvm/llvm-project/pull/65852
___
cfe-commits mailing list
@@ -2138,6 +2138,8 @@ class IRBuilderBase {
return Insert(CastInst::CreatePointerCast(V, DestTy), Name);
}
+ // With opaque pointers enabled, this is same as CreateAddressSpaceCast.
nikic wrote:
All the IRBuilder cast methods are no-ops if old type ==
nikic wrote:
Please don't use the term canon/canonicalize for this pass or tool. LLVM has an
existing notion of "canonicalization" which does coincide with what is being
done here.
https://github.com/llvm/llvm-project/pull/68176
___
cfe-commits
@@ -146,6 +146,13 @@ Non-comprehensive list of changes in this release
New Compiler Flags
--
+* ``-fverify-intermediate-code`` and it's complement
``-fno-verify-intermediate-code``.
+ Enables or disables verification of the generated LLVM IR.
+ It's
@@ -146,6 +146,13 @@ Non-comprehensive list of changes in this release
New Compiler Flags
--
+* ``-fverify-intermediate-code`` and it's complement
``-fno-verify-intermediate-code``.
+ Enables or disables verification of the generated LLVM IR.
+ It's
@@ -146,6 +146,13 @@ Non-comprehensive list of changes in this release
New Compiler Flags
--
+* ``-fverify-intermediate-code`` and it's complement
``-fno-verify-intermediate-code``.
+ Enables or disables verification of the generated LLVM IR.
+ It's
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/67772
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/67756
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
(Another alternative would be to use different check-prefixes for C/C++)
https://github.com/llvm/llvm-project/pull/67756
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
It looks like x86-bswap.c still has the C++ guarded code in it.
Any thoughts on
> Though I think we might be better off passing `-no-enable-noundef-analysis`
> to these tests, as noundef is really not what they want to test.
to avoid the test duplication?
nikic wrote:
@zygoloid Thanks for the explanation! I wasn't aware this fell under
unspecified behavior. It's weird that alignment information can survive a `void
*` cast, but it does make some sense.
What seems worrying here is that apparently GCC and Clang do not agree on
semantics in this
nikic wrote:
> I also noticed that LoadedSLocEntryTable uses 42 elements tables, which
> probably introduces some extra divisions to do the indexing. I can try
> switching to 32 elements.
I've tested the following change that forces power of two pages sizes, but it
did not have any impact:
nikic wrote:
Apart from that, the functional changes themselves look good to me.
https://github.com/llvm/llvm-project/pull/67756
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
For the clang tests you've split, the `.c` versions still have
`defined(__cplusplus)` checks, which doesn't make much sense.
Though I think we might be better off passing `-no-enable-noundef-analysis` to
these tests, as noundef is really not what they want to test.
Author: Nikita Popov
Date: 2023-10-02T12:40:20+02:00
New Revision: 3b25407d977d9ed3dbcaccd4f8850b65e95d70fd
URL:
https://github.com/llvm/llvm-project/commit/3b25407d977d9ed3dbcaccd4f8850b65e95d70fd
DIFF:
https://github.com/llvm/llvm-project/commit/3b25407d977d9ed3dbcaccd4f8850b65e95d70fd.diff
@@ -3732,14 +3732,18 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op,
const APInt ,
assert(Op.getResNo() == 0 &&
"We only compute knownbits for the difference here.");
-// TODO: Compute influence of the carry operand.
-if (Opcode ==
@@ -3732,14 +3732,18 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op,
const APInt ,
assert(Op.getResNo() == 0 &&
"We only compute knownbits for the difference here.");
-// TODO: Compute influence of the carry operand.
-if (Opcode ==
@@ -3732,14 +3732,18 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op,
const APInt ,
assert(Op.getResNo() == 0 &&
"We only compute knownbits for the difference here.");
-// TODO: Compute influence of the carry operand.
-if (Opcode ==
@@ -6380,7 +6380,71 @@ Instruction
*InstCombinerImpl::foldICmpUsingBoolRange(ICmpInst ) {
Y->getType()->isIntOrIntVectorTy(1) && Pred == ICmpInst::ICMP_ULE)
return BinaryOperator::CreateOr(Builder.CreateIsNull(X), Y);
+ // icmp eq/ne X, (zext/sext (icmp eq/ne X,
@@ -6380,7 +6380,71 @@ Instruction
*InstCombinerImpl::foldICmpUsingBoolRange(ICmpInst ) {
Y->getType()->isIntOrIntVectorTy(1) && Pred == ICmpInst::ICMP_ULE)
return BinaryOperator::CreateOr(Builder.CreateIsNull(X), Y);
+ // icmp eq/ne X, (zext/sext (icmp eq/ne X,
nikic wrote:
Looks like this causes a compile-time regression:
https://llvm-compile-time-tracker.com/compare.php?from=abcaebfe3aacb13d46be5e949fd6ed9b4321e2f6=4ae51570806ba5c5fcabe6d6dcbe52e3a5d5453b=instructions%3Au
About 0.5% at `O0`.
https://github.com/llvm/llvm-project/pull/66430
nikic wrote:
Uh, why are we allowed to assume that memcpy pointer arguments are aligned?
This looks like a miscompile to me.
A plain `int *` pointer is not required to be aligned, and memcpy works on
`void *` pointers, so I'm not sure where an alignment requirement would appear
from.
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/67788
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/67788
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3732,14 +3732,18 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op,
const APInt ,
assert(Op.getResNo() == 0 &&
"We only compute knownbits for the difference here.");
-// TODO: Compute influence of the carry operand.
-if (Opcode ==
https://github.com/nikic commented:
Looks fine to me.
https://github.com/llvm/llvm-project/pull/67788
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3732,14 +3732,18 @@ KnownBits SelectionDAG::computeKnownBits(SDValue Op,
const APInt ,
assert(Op.getResNo() == 0 &&
"We only compute knownbits for the difference here.");
-// TODO: Compute influence of the carry operand.
-if (Opcode ==
https://github.com/nikic created https://github.com/llvm/llvm-project/pull/67772
Pointer arithmetic on void pointers (a GNU extension) was going through a
different code path and bypassed the pointer-overflow sanitizer.
Fixes https://github.com/llvm/llvm-project/issues/66451.
>From
Author: Nikita Popov
Date: 2023-09-28T16:45:31+02:00
New Revision: fb2bdbb83d3913d9d32b28c1de3f3d8b4e6dfc8a
URL:
https://github.com/llvm/llvm-project/commit/fb2bdbb83d3913d9d32b28c1de3f3d8b4e6dfc8a
DIFF:
https://github.com/llvm/llvm-project/commit/fb2bdbb83d3913d9d32b28c1de3f3d8b4e6dfc8a.diff
https://github.com/nikic requested changes to this pull request.
If I understood correctly, what you're trying to do here is to apply an icmp
fold early before the sext -> zext information gets lost. I don't think this is
the correct way to approach the problem. The correct way is to preserve
nikic wrote:
Why does this need special handling in CGP instead of being a normal custom
lowering for FLDEXP?
https://github.com/llvm/llvm-project/pull/67552
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -6397,6 +6397,48 @@ static Value *simplifyBinaryIntrinsic(Function *F, Value
*Op0, Value *Op1,
return Constant::getNullValue(ReturnType);
break;
}
+ case Intrinsic::ptrmask: {
+// Fail loudly in case this is ever changed.
+// TODO: If vector types are
@@ -6397,6 +6397,48 @@ static Value *simplifyBinaryIntrinsic(Function *F, Value
*Op0, Value *Op1,
return Constant::getNullValue(ReturnType);
break;
}
+ case Intrinsic::ptrmask: {
+// Fail loudly in case this is ever changed.
+// TODO: If vector types are
https://github.com/nikic resolved
https://github.com/llvm/llvm-project/pull/67166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic resolved
https://github.com/llvm/llvm-project/pull/67166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -898,6 +910,53 @@ Value *InstCombinerImpl::SimplifyDemandedUseBits(Value *V,
APInt DemandedMask,
}
break;
}
+ case Intrinsic::ptrmask: {
+// Fail loudly in case this is ever changed.
+// Likely not much needs to be changed here to
https://github.com/nikic resolved
https://github.com/llvm/llvm-project/pull/67166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic resolved
https://github.com/llvm/llvm-project/pull/67166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6397,6 +6397,48 @@ static Value *simplifyBinaryIntrinsic(Function *F, Value
*Op0, Value *Op1,
return Constant::getNullValue(ReturnType);
break;
}
+ case Intrinsic::ptrmask: {
+// Fail loudly in case this is ever changed.
+// TODO: If vector types are
@@ -6380,7 +6380,69 @@ Instruction
*InstCombinerImpl::foldICmpUsingBoolRange(ICmpInst ) {
Y->getType()->isIntOrIntVectorTy(1) && Pred == ICmpInst::ICMP_ULE)
return BinaryOperator::CreateOr(Builder.CreateIsNull(X), Y);
+ // icmp eq/ne X, (zext/sext (icmp eq/ne X,
@@ -6380,7 +6380,69 @@ Instruction
*InstCombinerImpl::foldICmpUsingBoolRange(ICmpInst ) {
Y->getType()->isIntOrIntVectorTy(1) && Pred == ICmpInst::ICMP_ULE)
return BinaryOperator::CreateOr(Builder.CreateIsNull(X), Y);
+ // icmp eq/ne X, (zext/sext (icmp eq/ne X,
@@ -898,6 +910,53 @@ Value *InstCombinerImpl::SimplifyDemandedUseBits(Value *V,
APInt DemandedMask,
}
break;
}
+ case Intrinsic::ptrmask: {
+// Fail loudly in case this is ever changed.
+// Likely not much needs to be changed here to
@@ -6397,6 +6397,48 @@ static Value *simplifyBinaryIntrinsic(Function *F, Value
*Op0, Value *Op1,
return Constant::getNullValue(ReturnType);
break;
}
+ case Intrinsic::ptrmask: {
+// Fail loudly in case this is ever changed.
+// TODO: If vector types are
@@ -1985,6 +1985,28 @@ Instruction *InstCombinerImpl::visitCallInst(CallInst
) {
{InnerPtr, NewMask}));
}
}
+bool Changed = false;
+KnownBits Known = computeKnownBits(II, /*Depth*/ 0, II);
+// See if we can deduce
@@ -1985,6 +1985,28 @@ Instruction *InstCombinerImpl::visitCallInst(CallInst
) {
{InnerPtr, NewMask}));
}
}
+bool Changed = false;
+KnownBits Known = computeKnownBits(II, /*Depth*/ 0, II);
+// See if we can deduce
@@ -1985,6 +1985,28 @@ Instruction *InstCombinerImpl::visitCallInst(CallInst
) {
{InnerPtr, NewMask}));
}
}
+bool Changed = false;
+KnownBits Known = computeKnownBits(II, /*Depth*/ 0, II);
+// See if we can deduce
@@ -1984,10 +1984,30 @@ Instruction *InstCombinerImpl::visitCallInst(CallInst
) {
//-> (ptrmask p, (and A, B))
if (match(Op0, m_OneUse(m_Intrinsic(
m_Value(InnerPtr), m_Value(InnerMask) {
+ // See if combining the two masks is free.
@@ -6397,6 +6397,48 @@ static Value *simplifyBinaryIntrinsic(Function *F, Value
*Op0, Value *Op1,
return Constant::getNullValue(ReturnType);
break;
}
+ case Intrinsic::ptrmask: {
+// Fail loudly in case this is ever changed.
+// TODO: If vector types are
@@ -6397,6 +6397,48 @@ static Value *simplifyBinaryIntrinsic(Function *F, Value
*Op0, Value *Op1,
return Constant::getNullValue(ReturnType);
break;
}
+ case Intrinsic::ptrmask: {
+// Fail loudly in case this is ever changed.
+// TODO: If vector types are
@@ -6309,7 +6309,69 @@ Instruction
*InstCombinerImpl::foldICmpUsingBoolRange(ICmpInst ) {
Y->getType()->isIntOrIntVectorTy(1) && Pred == ICmpInst::ICMP_ULE)
return BinaryOperator::CreateOr(Builder.CreateIsNull(X), Y);
+ ICmpInst::Predicate Pred1, Pred2;
const
nikic wrote:
I think this is the right canonicalization at the IR level, as select allows
better analysis than zext(icmp). However, this seems to be universally worse
for the backend: https://llvm.godbolt.org/z/Yh7brfc8b So I think we would need
an SDAG undo transform. Interestingly, this
nikic wrote:
> ```
> define noundef nonnull ptr @foo() {
>%b = call ptr @bar()
>call void @use(ptr %p) willreturn nounwind
>ret ptr %b
> }
> ```
>
> If we add `nonnull` to `@bar` during inlining it can still make `%p` poison
> for its use in `@use`. I get it will trigger proper UB
nikic wrote:
> > It occurs to me that the current return attribute propagation is currently
> > buggy for poison-generating attributes: https://llvm.godbolt.org/z/x8n18q9Mj
> > In this case the argument to use() will now be poison as well, while before
> > inlining only the return value was
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/65845
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
It occurs to me that the current return attribute propagation is currently
buggy for poison-generating attributes: https://llvm.godbolt.org/z/x8n18q9Mj
In this case the argument to use() will now be poison as well, while before
inlining only the return value was poison.
This
nikic wrote:
Any numbers on what / how much this improves?
https://github.com/llvm/llvm-project/pull/66430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic review_requested
https://github.com/llvm/llvm-project/pull/65748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic review_request_removed
https://github.com/llvm/llvm-project/pull/65748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic review_request_removed
https://github.com/llvm/llvm-project/pull/65748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic review_request_removed
https://github.com/llvm/llvm-project/pull/65748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Nikita Popov
Date: 2023-08-29T11:43:57+02:00
New Revision: 14cc7a07727555102c52e711f476ec7671317d6a
URL:
https://github.com/llvm/llvm-project/commit/14cc7a07727555102c52e711f476ec7671317d6a
DIFF:
https://github.com/llvm/llvm-project/commit/14cc7a07727555102c52e711f476ec7671317d6a.diff
Author: Nikita Popov
Date: 2023-08-29T11:39:59+02:00
New Revision: 13a044c6993a914fc33549b72215e698a1cdef63
URL:
https://github.com/llvm/llvm-project/commit/13a044c6993a914fc33549b72215e698a1cdef63
DIFF:
https://github.com/llvm/llvm-project/commit/13a044c6993a914fc33549b72215e698a1cdef63.diff
Author: Nikita Popov
Date: 2023-08-21T11:44:35+02:00
New Revision: fa1b6e6b34eb6382c451f3a06a7c52d7ac6ada1d
URL:
https://github.com/llvm/llvm-project/commit/fa1b6e6b34eb6382c451f3a06a7c52d7ac6ada1d
DIFF:
https://github.com/llvm/llvm-project/commit/fa1b6e6b34eb6382c451f3a06a7c52d7ac6ada1d.diff
Author: Nikita Popov
Date: 2023-07-31T09:54:24+02:00
New Revision: 063b37e7b40ace03184923213bc9ead6aadee540
URL:
https://github.com/llvm/llvm-project/commit/063b37e7b40ace03184923213bc9ead6aadee540
DIFF:
https://github.com/llvm/llvm-project/commit/063b37e7b40ace03184923213bc9ead6aadee540.diff
401 - 500 of 720 matches
Mail list logo
