Add getPassInfo() function to llvm::Pass #3

c-a · 2014-01-27T13:03:47Z

When profiling rust compilation I found that llvm spends a lot of time in llvm::PassRegistry::getPassInfo(). To try to fix this I wrote a simple hacky patch for llvm which basically caches the result from llvm::PassRegistry::getPassInfo() in it's corresponding pass. Although hacky it works well in eliminating llvm::PassRegistry::getPassInfo() from my profiles and cuts approximately 50 seconds from a rustc-stage2 build in my testing.

I sent the patch to the llvm list (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131223/200046.html) asking for feedback on doing a proper fix but I haven't got any response yet. Anyway since this cuts compilation time quite considerably it may be worthwhile to include this in the rust fork of llvm for now.

-- Before --
Fraction spent in lvm::PassRegistry::getPassInfo() according to callgrind when compiling sudoku.rs: 14.01

After doing make rustc-stage1
time make -j4 rustc-stage2
real 5m56.428s
user 5m40.291s
sys 0m7.293s

-- After --
Fraction spent in lvm::PassRegistry::getPassInfo() according to callgrind when compiling sudoku.rs: 0.07

After doing make rustc-stage1
time make -j4 rustc-stage2
real 5m16.838s
user 4m55.682s
sys 0m7.536s

PassRegistry::getPass() is quite heavy since it involves taking a lock and looking up the info in a hashtable.

alexcrichton · 2014-01-27T17:28:25Z

Interesting! I'm really liking those improvements in compilation times.

I'm a little hesitant to merge this because we're really starting to diverge from LLVM master, but this is so much of a win I think that may override this. I'm curious what @brson thinks about this?

brson · 2014-01-27T20:06:57Z

Nice win.

Yeah, I'm resigned to taking any patches we need for the time being, so let's merge. It would be super-awesome though if you could get this merged upstream @c-a.

alexcrichton · 2014-01-27T20:36:48Z

I'll merge this and open a PR against mozilla/rust, I'll also rebase on top of the latest LLVM.

Thanks for this!

alexcrichton · 2014-01-27T21:07:44Z

cc rust-lang/rust#11853

@eddyb

This upgrade brings commit by @eddyb to help optimizations of virtual calls in a few places (llvm-mirror/llvm@6d2bd95) as well as a commit by @c-a to *greatly* improve the runtime of the optimization passes (rust-lang/llvm#3). Nice work to these guys!

lucab · 2014-01-28T11:04:08Z

@sylvestre @isanbard can some of the LLVM guys take a look at the above patch sent to the LLVM-commits ML and comment on the mergeability of this one upstream?

isanbard · 2014-01-28T11:31:17Z

On Jan 28, 2014, at 3:04 AM, Luca Bruno [email protected] wrote:

@sylvestre @isanbard can some of the LLVM guys take a look at the above patch sent to the LLVM-commits ML and comments on the mergeability of this upstream?

I doubt I’d be a good candidate to look at your patch, given that people on the Mozilla LLVM team were so unimpressed by me that they rejected me without even talking to me. Get someone else to do it. You may consider Chandler, who’s reworking all of the pass manager as we speak.

-bw

@eddyb

This upgrade brings commit by @eddyb to help optimizations of virtual calls in a few places (llvm-mirror/llvm@6d2bd95) as well as a commit by @c-a to *greatly* improve the runtime of the optimization passes (rust-lang/llvm#3). Nice work to these guys!

@eddyb

This upgrade brings commit by @eddyb to help optimizations of virtual calls in a few places (llvm-mirror/llvm@6d2bd95) as well as a commit by @c-a to *greatly* improve the runtime of the optimization passes (rust-lang/llvm#3). Nice work to these guys!

@t

…ify-libcall optimize a call to a llvm intrinsic to something that invovles a call to a C library call, make sure it sets the right calling convention on the call. e.g. extern double pow(double, double); double t(double x) { return pow(10, x); } Compiles to something like this for AAPCS-VFP: define arm_aapcs_vfpcc double @t(double %x) #0 { entry: %0 = call double @llvm.pow.f64(double 1.000000e+01, double %x) ret double %0 } declare double @llvm.pow.f64(double, double) #1 Simplify libcall (part of instcombine) will turn the above into: define arm_aapcs_vfpcc double @t(double %x) #0 { entry: %__exp10 = call double @__exp10(double %x) #1 ret double %__exp10 } declare double @__exp10(double) The pre-instcombine code works because calls to LLVM builtins are special. Instruction selection will chose the right calling convention for the call. However, the code after instcombine is wrong. The call to __exp10 will use the C calling convention. I can think of 3 options to fix this. 1. Make "C" calling convention just work since the target should know what CC is being used. This doesn't work because each function can use different CC with the "pcs" attribute. 2. Have Clang add the right CC keyword on the calls to LLVM builtin. This will work but it doesn't match the LLVM IR specification which states these are "Standard C Library Intrinsics". 3. Fix simplify libcall so the resulting calls to the C routines will have the proper CC keyword. e.g. %__exp10 = call arm_aapcs_vfpcc double @__exp10(double %x) #1 This works and is the solution I implemented here. Both solutions #2 and #3 would work. After carefully considering the pros and cons, I decided to implement #3 for the following reasons. 1. It doesn't change the "spec" of the intrinsics. 2. It's a self-contained fix. There are a couple of potential downsides. 1. There could be other places in the optimizer that is broken in the same way that's not addressed by this. 2. There could be other calling conventions that need to be propagated by simplify-libcall that's not handled. But for now, this is the fix that I'm most comfortable with. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203488 91177308-0d34-0410-b5e6-96231b3b80d8

The canonical form for the extended addressing mode (e.g., "[x1, w2, uxtw #3]" is for the MCInst to have the second register be the full 64-bit GPR64 register class. The instruction printer cleans up the output for display to show the 32-bit register instead, per the specification. This simplifies 205893 now that the aliasing is handled in the printer in 206495 so that the codegen path and the disassembler path give the same MCInst form. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206797 91177308-0d34-0410-b5e6-96231b3b80d8

@arr

For pattern like ((x >> C1) & Mask) << C2, DAG combiner may convert it into (x >> (C1-C2)) & (Mask << C2), which makes pattern matching of ubfx more difficult. For example: Given %shr = lshr i64 %x, 4 %and = and i64 %shr, 15 %arrayidx = getelementptr inbounds [8 x [64 x i64]]* @arr, i64 0, %i64 2, i64 %and %0 = load i64* %arrayidx With current shift folding, it takes 3 instrs to compute base address: lsr x8, x0, #1 and x8, x8, #0x78 add x8, x9, x8 If using ubfx, it only needs 2 instrs: ubfx x8, x0, #4, #4 add x8, x9, x8, lsl #3 This fixes bug 19589 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207702 91177308-0d34-0410-b5e6-96231b3b80d8

FastISel didn't take much advantage of the different addressing modes available to it on AArch64. This commit allows the ComputeAddress method to recognize more addressing modes that allows shifts and sign-/zero-extensions to be folded into the memory operation itself. For Example: lsl x1, x1, #3 --> ldr x0, [x0, x1, lsl #3] ldr x0, [x0, x1] sxtw x1, w1 lsl x1, x1, #3 --> ldr x0, [x0, x1, sxtw #3] ldr x0, [x0, x1] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215597 91177308-0d34-0410-b5e6-96231b3b80d8

…15597). Note: This was originally reverted to track down a buildbot error. Reapply without any modifications. Original commit message: FastISel didn't take much advantage of the different addressing modes available to it on AArch64. This commit allows the ComputeAddress method to recognize more addressing modes that allows shifts and sign-/zero-extensions to be folded into the memory operation itself. For Example: lsl x1, x1, #3 --> ldr x0, [x0, x1, lsl #3] ldr x0, [x0, x1] sxtw x1, w1 lsl x1, x1, #3 --> ldr x0, [x0, x1, sxtw #3] ldr x0, [x0, x1] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216013 91177308-0d34-0410-b5e6-96231b3b80d8

* If a scope has already been assigned a discriminator, do not reassign a nested discriminator for it. * If the file and line both match, even if the column does not match, we should assign a new discriminator for the stmt. original code: ; #1 int foo(int i) { ; #2 if (i == 3 || i == 5) return 100; else return 99; ; #3 } ; i == 3: discriminator 0 ; i == 5: discriminator 2 ; return 100: discriminator 1 ; return 99: discriminator 3 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251680 91177308-0d34-0410-b5e6-96231b3b80d8

Update the discriminator assignment algorithm * If a scope has already been assigned a discriminator, do not reassign a nested discriminator for it. * If the file and line both match, even if the column does not match, we should assign a new discriminator for the stmt. original code: ; #1 int foo(int i) { ; #2 if (i == 3 || i == 5) return 100; else return 99; ; #3 } ; i == 3: discriminator 0 ; i == 5: discriminator 2 ; return 100: discriminator 1 ; return 99: discriminator 3 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251685 91177308-0d34-0410-b5e6-96231b3b80d8

Update the discriminator assignment algorithm * If a scope has already been assigned a discriminator, do not reassign a nested discriminator for it. * If the file and line both match, even if the column does not match, we should assign a new discriminator for the stmt. original code: ; #1 int foo(int i) { ; #2 if (i == 3 || i == 5) return 100; else return 99; ; #3 } ; i == 3: discriminator 0 ; i == 5: discriminator 2 ; return 100: discriminator 1 ; return 99: discriminator 3 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251689 91177308-0d34-0410-b5e6-96231b3b80d8

….dbg.declare. The webp/snes9x build was generating more intermediate bitcasts than expected, so the fixup for making llvm.dbg.declare's first argument be an alloca was sometimes failing to find the alloca. I.e., some earlier pass like instcombine was already violating the contract that llvm.dbg.declare's first argument be an alloca or a function argument. Try to be more resilient and loop through more casts if needed. Technically llvm.dbg.declare's first argument doesn't *have* to be an alloca: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/086647.html However, ReplacePtrsWithInts does not handle converting llvm.dbg.declare parameters which are bitcasts, and ends up erasing the bitcasts. This causes us to drop debug info. An alternative is to fix up ReplacePtrsWithInts (TODO), but we need to make that work with DCE. That is, the conversions inserted by ReplacePtrsWithInts must not be used solely by llvm.dbg.declare, otherwise DCE will delete those conversions and leave us with a null argument to llvm.dbg.declare. Example program state prior to SimplifyAllocas: ; Function Attrs: nounwind readonly define internal fastcc i32 @png_sig_cmp(i8* readonly %sig, i32 %start, i32 %num_to_check) #3 { entry: %png_signature = alloca i64, align 8, !dbg !68085 %tmpcast = bitcast i64* %png_signature to [8 x i8]*, !dbg !68085 call void @llvm.dbg.declare(metadata [8 x i8]* %tmpcast, metadata !68092, metadata !45244), !dbg !68085 store i64 727905341920923785, i64* %png_signature, align 8, !dbg !68085 %cmp = icmp ugt i32 %num_to_check, 8, !dbg !68093 br i1 %cmp, label %if.end3, label %if.else, !dbg !68095 // ... if.end6: // ... %gep_int6 = ptrtoint [8 x i8]* %tmpcast to i32, !dbg !68108 // ... BUG= https://code.google.com/p/nativeclient/issues/detail?id=4203 [email protected] Review URL: https://codereview.chromium.org/1166253003.

…d VPlan for tests." Memory leaks in tests. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/6289/steps/check-llvm%20asan/logs/stdio Direct leak of 192 byte(s) in 1 object(s) allocated from: #0 0x554ea8 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:106 #1 0x56cef1 in llvm::VPlanTestBase::doAnalysis(llvm::Function&) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/Transforms/Vectorize/VPlanTestBase.h:53:14 #2 0x56bec4 in llvm::VPlanTestBase::buildHCFG(llvm::BasicBlock*) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/Transforms/Vectorize/VPlanTestBase.h:57:3 #3 0x571f1e in llvm::(anonymous namespace)::VPlanHCFGTest_testVPInstructionToVPRecipesInner_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/Transforms/Vectorize/VPlanHCFGTest.cpp:119:15 #4 0xed2291 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #5 0xed44c8 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #6 0xed5890 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #7 0xef3634 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #8 0xef27e0 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #9 0xebbc23 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #10 0xebbc23 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:51 #11 0x7f65569592e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) and more. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336718 91177308-0d34-0410-b5e6-96231b3b80d8

…ering" This reverts commit r337021. WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x1415cd65 in void write_signed<long>(llvm::raw_ostream&, long, unsigned long, llvm::IntegerStyle) /code/llvm-project/llvm/lib/Support/NativeFormatting.cpp:95:7 #1 0x1415c900 in llvm::write_integer(llvm::raw_ostream&, long, unsigned long, llvm::IntegerStyle) /code/llvm-project/llvm/lib/Support/NativeFormatting.cpp:121:3 #2 0x1472357f in llvm::raw_ostream::operator<<(long) /code/llvm-project/llvm/lib/Support/raw_ostream.cpp:117:3 #3 0x13bb9d4 in llvm::raw_ostream::operator<<(int) /code/llvm-project/llvm/include/llvm/Support/raw_ostream.h:210:18 #4 0x3c2bc18 in void printField<unsigned int, &(amd_kernel_code_s::amd_kernel_code_version_major)>(llvm::StringRef, amd_kernel_code_s const&, llvm::raw_ostream&) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:78:23 #5 0x3c250ba in llvm::printAmdKernelCodeField(amd_kernel_code_s const&, int, llvm::raw_ostream&) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:104:5 #6 0x3c27ca3 in llvm::dumpAmdKernelCode(amd_kernel_code_s const*, llvm::raw_ostream&, char const*) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:113:5 #7 0x3a46e6c in llvm::AMDGPUTargetAsmStreamer::EmitAMDKernelCodeT(amd_kernel_code_s const&) /code/llvm-project/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp:161:3 #8 0xd371e4 in llvm::AMDGPUAsmPrinter::EmitFunctionBodyStart() /code/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp:204:26 [...] Uninitialized value was created by an allocation of 'KernelCode' in the stack frame of function '_ZN4llvm16AMDGPUAsmPrinter21EmitFunctionBodyStartEv' #0 0xd36650 in llvm::AMDGPUAsmPrinter::EmitFunctionBodyStart() /code/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp:192 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337079 91177308-0d34-0410-b5e6-96231b3b80d8

A DAG-NOT-DAG is a CHECK-DAG group, X, followed by a CHECK-NOT group, N, followed by a CHECK-DAG group, Y. Let y be the initial directive of Y. This patch makes the following changes to the behavior: 1. Directives in N can no longer match within part of Y's match range just because y happens not to be the earliest match from Y. Specifically, this patch withdraws N's search range end from y's match range start to Y's match range start. 2. y can no longer match within X's match range, where a y match produced a reordering complaint, which is thus no longer possible. Specifically, this patch withdraws y's search range start from X's permitted range start to X's match range end, which was already the search range start for other members of Y. Both of these changes can only increase the number of test passes: #1 constrains the ability of CHECK-NOTs to match, and #2 expands the ability of CHECK-DAGs to match without complaints. These changes are based on discussions at: <http://lists.llvm.org/pipermail/llvm-dev/2018-May/123550.html> <https://reviews.llvm.org/D47106> which conclude that: 1. These changes simplify the FileCheck conceptual model. First, it makes search ranges for DAG-NOT-DAG more consistent with other cases. Second, it was confusing that y was treated differently from the rest of Y. 2. These changes add theoretical use cases for DAG-NOT-DAG that had no obvious means to be expressed otherwise. We can justify the first half of this assertion with the observation that these changes can only increase the number of test passes. 3. Reordering detection for DAG-NOT-DAG had no obvious real benefit. We don't have evidence from real uses cases to help us debate conclusions #2 and #3, but #1 at least seems intuitive. Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D48986 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337605 91177308-0d34-0410-b5e6-96231b3b80d8

…>> (32 - y) pattern" *Seems* to be breaking sanitizer-x86_64-linux-fast buildbot, the ELF/relocatable-versioned.s test: ==17758==MemorySanitizer CHECK failed: /b/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:191 "((kBlockMagic)) == ((((u64*)addr)[0]))" (0x6a6cb03abcebc041, 0x0) #0 0x59716b in MsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /b/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/msan/msan.cc:393 rust-lang#1 0x586635 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /b/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79 rust-lang#2 0x57d5ff in __sanitizer::InternalFree(void*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<__sanitizer::AP32> >*) /b/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:191 rust-lang#3 0x7fc21b24193f (/lib/x86_64-linux-gnu/libc.so.6+0x3593f) rust-lang#4 0x7fc21b241999 in exit (/lib/x86_64-linux-gnu/libc.so.6+0x35999) rust-lang#5 0x7fc21b22c2e7 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e7) rust-lang#6 0x57c039 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/lld+0x57c039) This reverts commit r345014. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@345017 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: As a bonus, this arguably improves the code by making it simpler. gcc 8 on Ubuntu 18.10 reports the following: ==39667==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffffff8ae0 at pc 0x555555dbfc68 bp 0x7fffffff8760 sp 0x7fffffff8750 WRITE of size 8 at 0x7fffffff8ae0 thread T0 #0 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Alloc_hider::_Alloc_hider(char*, std::allocator<char>&&) /usr/include/c++/8/bits/basic_string.h:149 rust-lang#1 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) /usr/include/c++/8/bits/basic_string.h:542 rust-lang#2 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) /usr/include/c++/8/bits/basic_string.h:6009 rust-lang#3 0x555555dbfc67 in searchableFieldType /home/nha/amd/build/san/llvm-src/utils/TableGen/SearchableTableEmitter.cpp:168 (...) Address 0x7fffffff8ae0 is located in stack of thread T0 at offset 864 in frame #0 0x555555dbef3f in searchableFieldType /home/nha/amd/build/san/llvm-src/utils/TableGen/SearchableTableEmitter.cpp:148 Reviewers: fhahn, simon_tatham, kparzysz Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53931 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@345749 91177308-0d34-0410-b5e6-96231b3b80d8

Add getPassInfo() function to llvm::Pass

511a86a

PassRegistry::getPass() is quite heavy since it involves taking a lock and looking up the info in a hashtable.

alexcrichton closed this Jan 27, 2014

alexcrichton mentioned this pull request Jan 27, 2014

Upgrade LLVM rust-lang/rust#11853

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add getPassInfo() function to llvm::Pass #3

Add getPassInfo() function to llvm::Pass #3

c-a commented Jan 27, 2014

alexcrichton commented Jan 27, 2014

brson commented Jan 27, 2014

alexcrichton commented Jan 27, 2014

alexcrichton commented Jan 27, 2014

lucab commented Jan 28, 2014

isanbard commented Jan 28, 2014

Add getPassInfo() function to llvm::Pass #3

Add getPassInfo() function to llvm::Pass #3

Conversation

c-a commented Jan 27, 2014

alexcrichton commented Jan 27, 2014

brson commented Jan 27, 2014

alexcrichton commented Jan 27, 2014

alexcrichton commented Jan 27, 2014

lucab commented Jan 28, 2014

isanbard commented Jan 28, 2014