[PATCH] D42249: [CodeGenCXX] annotate a GEP to a derived class with 'inbounds' (PR35909)

spatel created this revision. spatel added reviewers: efriedma, hfinkel, rjmccall, rsmith. Herald added a subscriber: mcrosier. I'm not sure if the code comment is adequate or even correct, but hopefully the change itself is valid. Eli cited this section of the standard in PR35909 ( https://bug

[PATCH] D42249: [CodeGenCXX] annotate a GEP to a derived class with 'inbounds' (PR35909)

spatel updated this revision to Diff 130488. spatel added a comment. Patch updated: 1. Removed comment that didn't add value. 2. Added test with no sanitizing, reduced from PR35909. https://reviews.llvm.org/D42249 Files: lib/CodeGen/CGClass.cpp test/CodeGenCXX/catch-undef-behavior.cpp te

[PATCH] D42249: [CodeGenCXX] annotate a GEP to a derived class with 'inbounds' (PR35909)

This revision was automatically updated to reflect the committed changes. Closed by commit rL322950: [CodeGenCXX] annotate a GEP to a derived class with 'inbounds' (PR35909) (authored by spatel, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.ll

[PATCH] D30834: [x86] these aren't the undefs you're looking for (PR32176)

spatel created this revision. Herald added a subscriber: mcrosier. x86 has undef SSE/AVX intrinsics that should represent a bogus register operand. This is not the same as LLVM's undef value which can take on multiple bit patterns. There are better solutions / follow-ups to this discussed here:

[PATCH] D30834: [x86] these aren't the undefs you're looking for (PR32176)

spatel added a comment. In https://reviews.llvm.org/D30834#698346, @craig.topper wrote: > Have you ran the tests all the way through to assembly and made sure we don't > regress? If we do regress, I wouldn't hold up fixing this, but we should at > least have bugs for what breaks. Yes - I spot

[PATCH] D30834: [x86] these aren't the undefs you're looking for (PR32176)

This revision was automatically updated to reflect the committed changes. Closed by commit rL297588: [x86] these aren't the undefs you're looking for (PR32176) (authored by spatel). Changed prior to commit: https://reviews.llvm.org/D30834?vs=91362&id=91507#toc Repository: rL LLVM https://re

[PATCH] D33406: PR28129 expand vector oparation to an IR constant.

spatel added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:7932 break; case X86::BI__builtin_ia32_cmppd256: ID = Intrinsic::x86_avx_cmp_pd_256; 1. Should we handle the 'pd256' version the same way? 2. How about the 0xb ('false') consta

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

spatel added inline comments. Comment at: llvm/test/Transforms/PhaseOrdering/X86/vector-reductions.ll:282 +; FIXME: this should be vectorized define i1 @cmp_lt_gt(double %a, double %b, double %c) { I don't think we need to worry about regressing this. It's not

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

spatel added inline comments. Comment at: llvm/test/Transforms/PhaseOrdering/unsigned-multiply-overflow-check.ll:20 +; FIXME: noundef should be attached to args define i1 @will_not_overflow(i64 %arg, i64 %arg1) { Any ideas about what it will take to get those

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

spatel added inline comments. Comment at: llvm/test/Transforms/PhaseOrdering/unsigned-multiply-overflow-check.ll:20 +; FIXME: noundef should be attached to args define i1 @will_not_overflow(i64 %arg, i64 %arg1) { aqjune wrote: > aqjune wrote: > > spatel wrote

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

spatel added inline comments. Comment at: llvm/test/Transforms/PhaseOrdering/unsigned-multiply-overflow-check.ll:20 +; FIXME: noundef should be attached to args define i1 @will_not_overflow(i64 %arg, i64 %arg1) { aqjune wrote: > nikic wrote: > > spatel wrote:

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

spatel created this revision. spatel added reviewers: MatzeB, neildhar, nikic, aqjune, dmgreen. Herald added a subscriber: mcrosier. spatel requested review of this revision. We got an unintended consequence of the optimizer getting smarter when compiling in a non-standard mode, and there's no go

[PATCH] D92270: [ConstantFold] Fold more operations to poison

spatel added inline comments. Comment at: llvm/lib/IR/ConstantFold.cpp:633 // the input constant. -return UndefValue::get(DestTy); +return PoisonValue::get(DestTy); } aqjune wrote: > neildhar wrote: > > spatel wrote: > > > MatzeB w

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

spatel added a comment. In D115804#3195002 , @nikic wrote: > Looks reasonable. Making float to int cast well defined is exactly why these > intrinsics exist. Should we also drop the "string-float-cast-overflow" > attribute, as UB is now prevented in a d

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG8c7f2a4f8719: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast… (authored by spatel). Herald added a project: clang. Chan

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

spatel added subscribers: kpn, sepavloff, andrew.w.kaylor. spatel added a comment. In D115804#3201044 , @craig.topper wrote: > What's the plan for constrained intrinsics versions of these intrinsics? The > IRBuilder calls for CreateFPToSI and CreateFPTo

[PATCH] D115886: [CodeGen] remove creation of FP cast function attribute

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG1965cc469539: [CodeGen] remove creation of FP cast function attribute (authored by spatel). Herald added a project: clang. Herald added a subscriber:

[PATCH] D98945: [BranchProbability] move options for 'likely' and 'unlikely'

This revision was automatically updated to reflect the committed changes. Closed by commit rGee8b53815ddf: [BranchProbability] move options for 'likely' and 'unlikely' (authored by spatel). Herald added a project: clang. Herald added a subscriber: cfe-commits. Repository: rG LLVM Github Monorep

[PATCH] D99898: [clang, test] Fix use of undef FileCheck var

spatel added inline comments. Comment at: clang/test/CodeGen/libcalls.c:127 // CHECK-NO-DAG: attributes [[NUW_RN]] = { nounwind readnone{{.*}} } +// CHECK-YES-NOT: attributes [[NUW_RN]] = { nounwind readnone{{.*}} } // CHECK-NO-DAG: attributes [[NUW_RNI]] = { nofree nosync noun

[PATCH] D93793: [IR] Let IRBuilder's CreateVectorSplat/CreateShuffleVector use poison as placeholder

spatel added inline comments. Comment at: llvm/include/llvm/IR/IRBuilder.h:2527 /// Create a unary shuffle. The second vector operand of the IR instruction /// is undefined. Value *CreateShuffleVector(Value *V, ArrayRef Mask, update code comment: undefin

[PATCH] D93923: Use unary CreateShuffleVector if possible

spatel accepted this revision. spatel added a comment. This revision is now accepted and ready to land. See inline comments to avoid bot failures - otherwise, LGTM. Thanks for the cleanup! Comment at: llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp:3193 IRBuilder<

[PATCH] D104854: Introduce intrinsic llvm.isnan

spatel added a comment. Is it intentional that we are not canonicalizing the intrinsic call back to `fcmp uno` in the default FP environment? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D104854/new/ https://reviews.llvm.org/D104854 _

[PATCH] D104854: Introduce intrinsic llvm.isnan

spatel added a comment. In D104854#2957471 , @sepavloff wrote: > In D104854#2957423 , @spatel wrote: > >> Is it intentional that we are not canonicalizing the intrinsic call back to >> `fcmp uno` in the default F

[PATCH] D104854: Introduce intrinsic llvm.isnan

spatel added a comment. In D104854#2957582 , @lebedev.ri wrote: > In D104854#2957529 , @spatel wrote: > >> In D104854#2957471 , @sepavloff >> wrote: >> >>> In D104854#29

[PATCH] D101759: [PowerPC] Scalar IBM MASS library conversion pass

spatel added a reviewer: efriedma. spatel added a comment. I'm not familiar with this library, and I haven't looked at current state of how we enable/map optional libs in a while... We definitely want to avoid adding another target option/debug flag, and if we can avoid relying on a function par

[PATCH] D108826: [SLP][LTO][WIP]Allow full SLP in LTO only at link time.

spatel added a comment. In D108826#2969604 , @ABataev wrote: > In D108826#2969594 , @lebedev.ri > wrote: > >> Aha, so full lto. That is consistent with the phase ordering dilemma @spatel >> discovered: D102002 <

<    1   2   3