[PATCH] D61046: Fix compilation warnings when compiling with GCC 7.3

nikic added inline comments. Comment at: llvm/trunk/unittests/IR/ConstantRangeTest.cpp:398-401 +#if defined(__GNUC__) && __GNUC__ >= 7 +// Silence warning: variable 'HaveInterrupt3' set but not used +(void)&HaveInterrupt3; +#endif tstellar wrote:

[PATCH] D61046: Fix compilation warnings when compiling with GCC 7.3

nikic added inline comments. Comment at: clang/trunk/unittests/AST/ASTImporterTest.cpp:4054 +} } shafik wrote: > aganea wrote: > > Fixes > > ``` > > [2097/2979] Building CXX object > > tools/clang/unittests/Tooling/CMakeFiles/ToolingTests.dir/LookupTest

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

nikic added a comment. Numbers for the newest version: https://llvm-compile-time-tracker.com/compare.php?from=183342c0a9850e60dd7a004b651c83dfb3a7d25e&to=eabcf534fe8760d14c95b40f07c61450c819d643&stat=instructions This is now a geomean 0.2% regressions, and I don't see any large outliers for ind

[PATCH] D84713: [DominatorTree] Simplify ChildrenGetter.

nikic added a comment. This change had a significant negative compile-time impact: https://llvm-compile-time-tracker.com/compare.php?from=0b161def6cacff1a63d3cf1a1efe95b550814d7a&to=e22de4e46d1dd1aacc3a7060d24bcbe89908ba6c&stat=instructions Repository: rG LLVM Github Monorepo CHANGES SINCE L

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

nikic added a comment. This change causes a 2.5% compile-time regression across the board, see http://llvm-compile-time-tracker.com/compare.php?from=37bcf2df01cfa47e4509a5d225a23e2ca95005e6&to=a90374988e4eb8c50d91e11f4e61cdbd5debb235&stat=instructions. Can you please try to find a cheaper way to

[PATCH] D77632: [TLI] Per-function fveclib for math library used for vectorization

nikic added a comment. This change causes a ~0.5% compile-time regressions: http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions This is quite a lot as these things go, so it would be great if

[PATCH] D77632: [TLI] Per-function fveclib for math library used for vectorization

nikic added a comment. I gave D77952 a try (on top of this one), but didn't see a significant improvement from that change. Looking at the callgrind output for compilation of a **small** file, I see 52M total instructions, 4 calls to TLII initialization, where

[PATCH] D83013: [LPM] Port CGProfilePass from NPM to LPM

nikic requested changes to this revision. nikic added inline comments. This revision now requires changes to proceed. Comment at: llvm/test/Other/opt-O2-pipeline.ll:289 +; CHECK-NEXT: Branch Probability Analysis +; CHECK-NEXT: Block Frequency Analysis ; CHECK-NEX

[PATCH] D83013: [LPM] Port CGProfilePass from NPM to LPM

nikic added inline comments. Comment at: llvm/test/Other/opt-O2-pipeline.ll:289 +; CHECK-NEXT: Branch Probability Analysis +; CHECK-NEXT: Block Frequency Analysis ; CHECK-NEXT: FunctionPass Manager hans wrote: > nikic wrote: > > Is it possibl

[PATCH] D83402: ParsedAttrInfo: Change spelling to use StringRef instead of const char*

nikic added a comment. This change looks reasonable to me in terms of coding style, however I'm not seeing any compile-time changes in terms of instructions retired myself (https://llvm-compile-time-tracker.com/compare.php?from=8691544a276744474ff04b71d7e220069435c7fe&to=75b126ecf7b5a0ce8c04cb46

[PATCH] D83013: [LPM] Port CGProfilePass from NPM to LPM

nikic accepted this revision. nikic added a comment. LG from my side. New compile-time numbers: https://llvm-compile-time-tracker.com/compare.php?from=0b39d2d75275b80994dac06b7ad05031cbd09393&to=fd070b79e063fff2fad3cd4a467f64dfca83eb90&stat=instructions It's nearly neutral now. =

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

nikic added a comment. Numbers for the new patch: https://llvm-compile-time-tracker.com/compare.php?from=c0308fd154f9a945608bd42630dc81dce5edfb40&to=e6e3534e77961cfa65d36828de5c75f36a25d009&stat=instructions The regression is definitely smaller now, but still fairly large. E.g. > 2% on mafft.

[PATCH] D81728: [InstCombine] Add target-specific inst combining

nikic added inline comments. Comment at: llvm/include/llvm/Analysis/TargetTransformInfo.h:540 + bool instCombineIntrinsic(InstCombiner &IC, IntrinsicInst &II, +Instruction **ResultI) const; + bool simplifyDemandedUseBitsIntrinsic(InstCombiner &IC, In

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

nikic added a comment. In D77341#2144974 , @asbirlea wrote: > Thank you for the testing. Could you help with with instructions on how to > run the tracker myself? > My local testing showed a negligible regression for mafft and a negligible > improvement

[PATCH] D81678: Introduce noundef attribute at call sites for stricter poison analysis

nikic added inline comments. Comment at: llvm/lib/Transforms/Utils/CodeExtractor.cpp:932 case Attribute::NoCfCheck: + case Attribute::NoUndef: break; Not familiar with this code, but based on the placement of other similar attributes like no

[PATCH] D77621: ADT: SmallVector size & capacity use word-size integers when elements are small.

nikic reopened this revision. nikic added a comment. This revision is now accepted and ready to land. I have reverted this change, because it causes a 1% compile-time

[PATCH] D77621: Change BitcodeWriter buffer to std::vector instead of SmallVector.

nikic added a comment. In D77621#157 , @dblaikie wrote: > @nikic any sense of the noise floor/level on these measurements? It doesn't > /look/ like there's much left in this that would cause problems. & I assume > these measurements were made on an o

[PATCH] D77621: Change BitcodeWriter buffer to std::vector instead of SmallVector.

nikic added a comment. In D77621#2000237 , @nikic wrote: > > Perhaps you could move the value computation into a constexpr variable & > > just return that as needed. (could be a static local constexpr, I guess - > > to avoid the issues around linkage of

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

nikic accepted this revision. nikic added inline comments. Comment at: llvm/include/llvm/ADT/SmallVector.h:19 #include "llvm/Support/Compiler.h" +#include "llvm/Support/ErrorHandling.h" #include "llvm/Support/MathExtras.h" Is this include still needed? ==

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

nikic added inline comments. Comment at: llvm/include/llvm/ADT/SmallVector.h:84 +template const size_t SmallVectorBase::SizeTypeMax; + dblaikie wrote: > nikic wrote: > > Is this needed? I don't think it makes a lot of sense to allow odr-use of > > `SizeTypeMa

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

nikic updated this revision to Diff 260105. nikic added a comment. Herald added subscribers: cfe-commits, Kayjukh, frgossen, grosul1, Joonsoo, liufengdb, lucyrfox, mgester, arpith-jacob, nicolasvasilache, antiagainst, shauheen, jpienaar, rriddle, mehdi_amini, asbirlea, jfb, george.burgess.iv. Her

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

nikic added a comment. In D78862#2003684 , @arsenm wrote: > FWIW I think this attribute should be replaced with a data layout property, > so this would eventually be removed Is this change planned more for the near term or the long term? I'm not really

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

nikic added a comment. @arsenm If the `null-pointer-is-valid` attribute is moved into the data layout, I'm wondering how Clang's `-fno-delete-null-pointer-checks` option would work or what it would be replaced with. In Rust it is possible to define a custom target, which also defines a custom d

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

nikic updated this revision to Diff 261279. nikic marked an inline comment as done. nikic added a comment. Rebase over committed NFC changes. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78862/new/ https://reviews.llvm.org/D78862 Files: clang/l

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

nikic added a comment. @browneee Looks like LLVM already defines `LLVM_PTR_SIZE` as a more portable version of `__SIZEOF_POINTER__`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77621/new/ https://reviews.llvm.org/D77621 __

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

nikic updated this revision to Diff 261375. nikic added a comment. Fix rebase mistake in test Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78862/new/ https://reviews.llvm.org/D78862 Files: clang/lib/CodeGen/CGCall.cpp clang/test/CodeGen/delet

[PATCH] D84959: [NewPM][LVI] Abandon LVI after CVP

This revision was automatically updated to reflect the committed changes. Closed by commit rG25af353b0e74: [NewPM][LVI] Abandon LVI after CVP (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-commits. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTIO

[PATCH] D83360: [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X

nikic added a comment. D85684 has landed, so we can try reapplying this change. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83360/new/ https://reviews.llvm.org/D83360 ___

[PATCH] D84713: [DominatorTree] Simplify ChildrenGetter.

nikic added a comment. The regression here seems to be because operations on an empty GraphDiff don't optimize out. Not going through GraphDiff but using the same basic logic (https://github.com/llvm/llvm-project/commit/4c6a5de8131183ff88f52cc3dda67180e31501a1 -- going through a separate method

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

nikic added a comment. Herald added a subscriber: stephenneuendorffer. Ping Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78862/new/ https://reviews.llvm.org/D78862 ___ cfe-commits mailing list cfe-com

[PATCH] D75936: Add a Pass to X86 that builds a Condensed CFG for Load Value Injection (LVI) Gadgets [4/6]

nikic added a comment. This change causes a 0.8% compile-time regression for unoptimized builds . Based on the pipeline test diffs, I expe

[PATCH] D75936: Add a Pass to X86 that builds a Condensed CFG for Load Value Injection (LVI) Gadgets [4/6]

nikic added a comment. In D75936#2032090 , @craig.topper wrote: > In D75936#2032078 , @sconstab wrote: > > > In D75936#2032027 , @nikic wrote: > > > > > This change causes a

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

This revision was automatically updated to reflect the committed changes. Closed by commit rGf89f7da999f3: [IR] Convert null-pointer-is-valid into an enum attribute (authored by nikic). Changed prior to commit: https://reviews.llvm.org/D78862?vs=261375&id=264285#toc Repository: rG LLVM Githu

[PATCH] D131475: [Flang] Use find_program() to find clang-tblgen

This revision was automatically updated to reflect the committed changes. Closed by commit rGc04eab8c78e5: [Flang] Use find_program() to find clang-tblgen (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-commits. Repository: rG LLVM Github Monorepo CHANGES SIN

[PATCH] D129833: Use @llvm.threadlocal.address intrinsic to access TLS

nikic added a comment. In D129833#3727881 , @ChuanqiXu wrote: > And I am working on adding Align properties. But I meet problems since the > alignment of threadlocal_address intrinsic depends on its argument so we > can't set the alignment for its decla

[PATCH] D132352: Introduce noread_thread_id to address the thread identification problem in coroutines

nikic added a comment. Okay, this is a bit tricky because we have three different things: 1. The noread_thread_id attribute, the lack of which was causing issues with intrinsics in the previous version 2. The meaning of the readnone (etc) attributes, which for pragmatic reasons has to exclude t

[PATCH] D133316: [OpenMP] Mark -fopenmp-implicit-rpath as NoArgumentUnused

This revision was automatically updated to reflect the committed changes. Closed by commit rG71797797f7a7: [OpenMP] Mark -fopenmp-implicit-rpath as NoArgumentUnused (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-commits. Repository: rG LLVM Github Monorepo C

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

nikic added a comment. I've reverted this change because it causes major llvm-test-suite breakage. You likely need to pin many tests to use `-std=c++14`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131465/new/ https://reviews.llvm.org/D131465 _

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

nikic added a comment. In D131465#3776537 , @MaskRay wrote: > In D131465#3776515 , @nikic wrote: > >> I've reverted this change because it causes major llvm-test-suite breakage. >> You likely need to pin many tes

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

nikic added a comment. In D131465#3776599 , @nikic wrote: > It looks like the switch to `-std=c++17` has some major compile-time impact: > http://llvm-compile-time-tracker.com/compare.php?from=047c7aa96dadf8a2c71a29e2df610d628d9e7e3e&to=3e99b8d947ac02483

[PATCH] D133405: [Linux] Hack around Linux/sparc

nikic added a comment. > I've been using this hack to work around the Linux/sparc64 compile failure > described in Issue #47994, especially since the underlying glibc PR > build/27558 doesn't seem to be making progress and some fix is required to > have LLVM build on sparc64-unknown-linux-gnu a

[PATCH] D133405: [Linux] Hack around Linux/sparc

nikic added a comment. In D133405#3782136 , @glaubitz wrote: > In D133405#3782092 , @nikic wrote: > >>> I've been using this hack to work around the Linux/sparc64 compile failure >>> described in Issue #47994, es

[PATCH] D133800: [Clang 15.0.1] Downgrade implicit int and implicit function declaration to warning only

nikic added a comment. I tested this patch as well and saw the same failures as @mgorny. Here's the additional patch I had to apply to make this pass: diff --git a/clang/test/CodeGen/PowerPC/builtins-ppc-p8vector.c b/clang/test/CodeGen/PowerPC/builtins-ppc-p8vector.c index af3d5c7d066b..3c5

[PATCH] D133800: [Clang 15.0.1] Downgrade implicit int and implicit function declaration to warning only

nikic added a comment. @mgorny Yeah, that was a testing fail on my side. I've updated it to a hopefully correct version. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133800/new/ https://reviews.llvm.org/D133800 __

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

nikic added a comment. Which intrinsic are you working on here? If this is about the mm_undefined intrinsics, why do we need to change those from the current status quo of using a zero value instead of undef? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.ll

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

nikic added a comment. In D103874#3611507 , @aqjune wrote: > In D103874#3611483 , @nikic wrote: > >> Which intrinsic are you working on here? If this is about the mm_undefined >> intrinsics, why do we need to cha

[PATCH] D125795: [IR] Remove support for extractvalue constant expression

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG5548e807b577: [IR] Remove support for extractvalue constant expression (authored by nikic). Herald added a project: clang. Herald added a subscriber:

[PATCH] D128792: [ConstExpr] Don't create insertvalue expressions

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG9ac386495d3c: [ConstExpr] Don't create insertvalue expressions (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-com

[PATCH] D129009: [LTO] Fix LTO for aliased IFuncs

nikic added inline comments. Comment at: llvm/lib/Analysis/ModuleSummaryAnalysis.cpp:654 + // summary for aliasee will not be emitted. + if (Aliasee->getValueID() != Value::ValueTy::GlobalIFuncVal) { +bool NonRenamableLocal = isNonRenamableLocal(A); MaskRay

[PATCH] D125291: Introduce @llvm.threadlocal.address intrinsic to access TLS variable

nikic added a comment. FWIW the bitcode patch has landed, so implementing the variant using a token type should be possible now. I'm not sure whether it's better to start with the current patch where the intrinsic is optional, or go directly to the one where it is required.

[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

nikic added a comment. @HanKuanChen Thanks for the report! I've landed a fix for this test case in https://github.com/llvm/llvm-project/commit/dc969061c68e62328607d68215ed8b9ef4a1e4b1. This is based on making SimplifyCFG behave more like JumpThreading, which does not have an infinite loop for t

[PATCH] D128820: [ConstExpr] Don't create div/rem expressions

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG935570b2ad80: [ConstExpr] Don't create div/rem expressions (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-commits

[PATCH] D128820: [ConstExpr] Don't create div/rem expressions

nikic added inline comments. Comment at: llvm/lib/IR/Constants.cpp:2368-2379 +bool ConstantExpr::isDesirableBinOp(unsigned Opcode) { + assert(Instruction::isBinaryOp(Opcode) && "Argument must be binop opcode"); + switch (Opcode) { + case Instruction::UDiv: + case Instruction:

[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

nikic added a comment. I ended up reverting this patch in https://github.com/llvm/llvm-project/commit/a4772cbaf0dc717ab6b4639272ca2910897613f0, because I reduced another infinite loop (https://github.com/llvm/llvm-project/issues/56203) to it as well, which makes it the third one. It's probably

[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

nikic added a comment. @nathanchance Thanks for the report. I've applied the obvious fix in https://github.com/llvm/llvm-project/commit/20962c1240691d25b21ce425313c81eed0b1b358. However, I think that this (and similar limitations relating to critical edge splitting) might actually be unnecessar

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG8a72391f609f: [IR] Require intrinsic struct return type to be anonymous (authored by nikic). Herald added a project: clang. Herald added a subscriber

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

nikic added a comment. @uabelho You shouldn't need to update intrinsic definitions (though you might want to update how you codegen the intrinsics). It sounds like the auto-upgrade code is going into an infinite loop in your case, but it's not really obvious to me how/why that would happen (or

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

nikic added a comment. Oh wait, do I see correctly that your intrinsic returns an overloaded type that happens to be a struct, rather than returning a struct defined in the intrinsic definition? I hadn't considered that case, and it's possible the auto-upgrade code is broken for that. Reposit

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

nikic added a comment. @uabelho Can you please check whether https://github.com/llvm/llvm-project/commit/d6887256c2cae1b1b721bd47459be6d86003db6f fixes the problem you're seeing? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D122471/new/ https://r

[PATCH] D122789: [compiler-rt] [scudo] Use -mcrc32 on x86 when available

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. Not familiar with this code, but the newest version does resolve the build failure with GCC, so I guess this is fine. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D122789/new/ https://

[PATCH] D123034: [OpaquePtrs][Clang] Add -opaque-pointers/-no-opaque-pointers cc1 options

This revision was automatically updated to reflect the committed changes. Closed by commit rGd69e9f9d8978: [OpaquePtrs][Clang] Add -opaque-pointers/-no-opaque-pointers cc1 options (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-commits. Repository: rG LLVM Git

[PATCH] D123126: [cmake] Remove LLVM_ENABLE_NEW_PASS_MANAGER cmake option

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGed4e6e03981a: [cmake] Remove LLVM_ENABLE_NEW_PASS_MANAGER cmake option (authored by nikic). Herald added a project: clang. Herald added a subscriber:

[PATCH] D130268: [NFC] Add SmallVector constructor to allow creation of SmallVector from ArrayRef of items convertible to type T

nikic added a comment. I think my only concern with this change is that it will also allow some implicit ArrayRef constructors. For example, this will permit creating a SmallVector from `std::array`, `std::vector`, or just `T` -- but only if `ArrayRef` is in scope. This seems somewhat dangerous

[PATCH] D129954: [CodeGen][inlineasm] assume the flag output of inline asm is boolean value

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LGTM. After some further consideration, implementing this properly in LLVM would probably take more effort than is worthwhile (especially as this is target-specific functionality, so we'd actual

[PATCH] D130268: [NFC] Add SmallVector constructor to allow creation of SmallVector from ArrayRef of items convertible to type T

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LGTM In D130268#3686811 , @yurai007 wrote: > In D130268#3684244 , @nikic wrote: > >> I think my only concern w

[PATCH] D130766: [SPIR-V] Disable opaque pointers in relese 15

nikic added reviewers: jcranmer-intel, opaque-pointers. nikic added a comment. LG from my side, as a temporary workaround. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130766/new/ https://reviews.llvm.org/D130766 ___ cfe-commits mailing list

[PATCH] D125291: Introduce @llvm.threadlocal.address intrinsic to access TLS variable

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LG. Now that LLVM 15 has branched, I think it is safe to land this, and there will be enough time before LLVM 16 to convert it to the token variant. Comment at: llvm/docs/Lang

[PATCH] D130689: [LLVM] Update C++ standard to 17

nikic added a comment. In D130689#3690258 , @thieta wrote: > In D130689#3689157 , @thakis wrote: > >> Is it expected and intentional that this increases the mac deployment target >> to 10.12? > > I wasn't aware o

[PATCH] D130268: [NFC] Add SmallVector constructor to allow creation of SmallVector from ArrayRef of items convertible to type T

nikic accepted this revision. nikic added a comment. Still LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130268/new/ https://reviews.llvm.org/D130268 ___ cfe-commits mailing list cfe-commits@lists.l

[PATCH] D130754: [X86] Support ``-mindirect-branch-cs-prefix`` for call and jmp to indirect thunk

nikic added a comment. This change caused a significant compile-time regression for `O0` builds (about 1%): http://llvm-compile-time-tracker.com/compare.php?from=45bae1be90472c696f6ba3bb4f8fabee76040fa9&to=6f867f9102838ebe314c1f3661fdf95700386e5a&stat=instructions At a guess, fetching a module

[PATCH] D131282: [mlir] fix `add_tablegen()` macro to allow installing mlir-pdll

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LGTM Comment at: llvm/cmake/modules/TableGen.cmake:147 + cmake_parse_arguments(ADD_TABLEGEN "${options}" "${oneValueArgs}" +"${multiValueArgs}" ${ARGN}) +

[PATCH] D131351: [C] Default implicit function pointer conversions diagnostic to be an error

nikic added a comment. This seems to break the test-suite build: FAILED: CTMark/ClamAV/CMakeFiles/clamscan.dir/libclamav_readdb.c.o /root/llvm-compile-time-tracker/llvm-test-suite-build/tools/timeit --summary CTMark/ClamAV/CMakeFiles/clamscan.dir/libclamav_readdb.c.o.time /root/llvm-compil

[PATCH] D106184: [BPF] Use elementtype attribute for preserve.array/struct.index intrinsics

nikic added inline comments. Comment at: llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp:303 CInfo.RecordAlignment = DL->getABITypeAlign(CInfo.Base->getType()->getPointerElementType()); return true; I noticed too late that this intrinsic also u

[PATCH] D106184: [BPF] Use elementtype attribute for preserve.array/struct.index intrinsics

nikic closed this revision. nikic added a comment. Landed as https://github.com/llvm/llvm-project/commit/be5af50e7d028849bf2fab5f4b0f2ad36ae56e11, missed the "Differential Revision" tag. For the record, the problem with the autoupgrade test was PEBKAC: The textual diff that gets uploaded to Ph

[PATCH] D106401: [CUDA, MemCpyOpt] Add a flag to force-enable memcpyopt and use it for CUDA.

nikic added a comment. Would the variant of the original patch at D106769 be sufficient for your purposes? Or are you also interested in the optimizations that introduce new memset/memcpy? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION htt

[PATCH] D121135: [NFC][Clang][OpaquePtr] Remove calls to Address::deprecated in a couple more files

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D121135/new/ https://reviews.llvm.org/D121135 ___ c

[PATCH] D120527: [OpaquePtr][AArch64] Use elementtype on ldxr/stxr

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LGTM. You probably want to add these intrinsics to the auto-upgrade code in `BitcodeReader::propagateAttributeTypes()` as well. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D120527: [OpaquePtr][AArch64] Use elementtype on ldxr/stxr

nikic added a comment. @aeubanks Do you plan to take care of the corresponding arm intrinsics as well? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D120527/new/ https://reviews.llvm.org/D120527 ___ cfe-c

[PATCH] D121847: [OpaquePtr][ARM] Use elementtype on ldrex/ldaex/stlex/strex

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D121847/new/ https://reviews.llvm.org/D121847 ___ c

[PATCH] D122046: [clang] Remove Address::deprecated from MveEmitter

nikic added inline comments. Comment at: clang/utils/TableGen/MveEmitter.cpp:1197 +const Type *Ty = nullptr; +if (auto *DI = dyn_cast(D->getArg(0))->getOperator()) + if (auto *PTy = dyn_cast(getType(DI, Param))) Should be either `cast` or check for n

[PATCH] D122199: [NFC][Clang][OpaquePtr] Remove calls to Address::deprecated in TargetInfo.cpp

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D122199/new/ https://reviews.llvm.org/D122199 ___ c

[PATCH] D115924: [ConstantFolding] Unify handling of load from uniform value

nikic added inline comments. Comment at: llvm/lib/Analysis/ConstantFolding.cpp:722 + (Ty->isIntOrIntVectorTy() || Ty->isFPOrFPVectorTy())) +return Constant::getAllOnesValue(Ty); + return nullptr; cameron.mcinally wrote: > Sorry for the late comment, but

[PATCH] D123122: [OpaquePtr][Clang] Add CLANG_ENABLE_OPAQUE_POINTERS cmake option

This revision was automatically updated to reflect the committed changes. Closed by commit rG5390606aa963: [OpaquePtr][Clang] Add CLANG_ENABLE_OPAQUE_POINTERS cmake option (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-commits. Changed prior to commit: https:

[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

nikic added a comment. Looks like this causes a relocation failure on this buildbot: https://lab.llvm.org/buildbot/#/builders/169/builds/7311 ld.lld: error: relocation R_MIPS_64 cannot be used against local symbol; recompile with -fPIC >>> defined in ScudoUnitTestsObjects.wrappers_cpp_test.

[PATCH] D123115: [OpaquePtrs][Clang] Add -no-opaque-pointers to tests

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG532dc62b9075: [OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC) (authored by nikic). Herald added a project: clang. Herald added a subscribe

[PATCH] D115924: [ConstantFolding] Unify handling of load from uniform value

nikic added inline comments. Comment at: llvm/lib/Analysis/ConstantFolding.cpp:722 + (Ty->isIntOrIntVectorTy() || Ty->isFPOrFPVectorTy())) +return Constant::getAllOnesValue(Ty); + return nullptr; cameron.mcinally wrote: > nikic wrote: > > cameron.mcinal

[PATCH] D123376: [llvm-lto] Remove support for legacy pass manager

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG2121dc5b158b: [llvm-lto] Remove support for legacy pass manager (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-co

[PATCH] D123300: [Clang] Enable opaque pointers by default

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG702d5de4380b: [Clang] Enable opaque pointers by default (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-commits.

[PATCH] D123547: [docs] Mention that we are in the process of removing the legacy PM for the optimization pipeline

nikic added inline comments. Comment at: clang/docs/ClangCommandLineReference.rst:4 NOTE: This file is automatically generated by running clang-tblgen -gen-opt-docs. Do not edit this file by hand!! --- -

[PATCH] D123300: [Clang] Enable opaque pointers by default

nikic added a comment. @mstorsjo Thanks for the report, the issue should be fixed by https://github.com/llvm/llvm-project/commit/8d5c8d57c637d898094af323d1888ea5a3364f8c. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123300/new/ https://reviews.ll

[PATCH] D123300: [Clang] Enable opaque pointers by default

nikic added a comment. @vitalybuka Are there any instructions on how to reproduce failures from this buildbot? It seems like this needs more than a simple bootstrap build due to the need for instrumented libcxx? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews

[PATCH] D123300: [Clang] Enable opaque pointers by default

nikic added a comment. Okay, I managed to reproduce this using the instructions from https://github.com/google/sanitizers/wiki/MemorySanitizerBootstrappingClang. Reduced to these two variants for `-passes=msan`: target triple = "x86_64-unknown-linux-gnu" define void @test(i8* %p, i32* by

[PATCH] D123300: [Clang] Enable opaque pointers by default

nikic added a comment. I've put up https://reviews.llvm.org/D123602 to fix the msan issue. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123300/new/ https://reviews.llvm.org/D123300 ___ cfe-commits maili

[PATCH] D123547: [docs] Mention that we are in the process of removing the legacy PM for the optimization pipeline

nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LG Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123547/new/ https://reviews.llvm.org/D123547 ___ cfe

[PATCH] D123300: [Clang] Enable opaque pointers by default

nikic added a comment. @mstorsjo Thanks! I've reduced this to a crash in `-argpromotion`: efine void @caller() { call i32 @callee(ptr null) ret void } define internal void @callee(ptr %p) { ret void } Similar issue with function type mismatch. Repository: rG LLVM Githu

[PATCH] D123609: [Clang] Remove support for legacy pass manager

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG2978d026819b: [Clang] Remove support for legacy pass manager (authored by nikic). Herald added a project: clang. Herald added a subscriber: cfe-commi

[PATCH] D123300: [Clang] Enable opaque pointers by default

nikic added a comment. @uabelho The IR is correct, but requires using `opt -opaque-pointers` explicitly. Normally, opaque pointer mode is automatically enabled, but there is no explicit mention of `ptr` in the IR. Not sure if we can do anything to improve that before the default on the opt side

[PATCH] D123609: [Clang] Remove support for legacy pass manager

nikic added a comment. In D123609#3451320 , @HaohaiWen wrote: > Hi @nikic, > We recently noticed legacy PM was removed from many places. > Does community plan to remove legacy PM completely? > Do you know when will CG switch to new PM? > Thanks. At this

[PATCH] D123957: Update the developer policy to mention release notes

nikic requested changes to this revision. nikic added inline comments. This revision now requires changes to proceed. Comment at: llvm/docs/DeveloperPolicy.rst:195 +* Adding, removing, or regrouping a diagnostic. +* Fixing a bug (please link to the issue fixed in the bug database

[PATCH] D123300: [Clang] Enable opaque pointers by default

nikic added a comment. @markus Without tracing through it in detail, I'd guess that without opaque pointers this creates two getelementptr constant expressions that get folded together. With opaque pointers, the first one (which would be a zero-index GEP) is omitted, and only the second one is

  1   2   3   4   5   >