1.76% performance loss in VRP due to inlining
Hi folks!
In implementing prange (pointer ranges), I have found a 1.74% slowdown
in VRP, even without any code path actually using the code. I have
tracked this down to irange::get_bitmask() being compiled differently
with and without the bare bones patch. With the patch,
irange::get_bitmask() has a lot of code inlined into it, particularly
get_bitmask_from_range() and consequently the wide_int_storage code.
I don't know whether this is expected behavior, and if it is, how to
mitigate it. I have tried declaring get_bitmask_from_range() inline,
but that didn't help. OTOH, using __attribute__((always_inline))
helps a bit, but not entirely. What does help is inlining
irange::get_bitmask() entirely, but that seems like a big hammer.
The overall slowdown in compilation is 0.26%, because VRP is a
relatively fast pass, but a measurable pass slowdown is something we'd
like to avoid.
What's the recommended approach here?
For the curious, I am attaching before and after copies of
value-range.s. I am also attaching the two patches needed to
reproduce the problem on mainline. The first patch is merely setup.
It is the second patch that exhibits the problem. Notice there are no
uses of prange yet.
Thanks.
Aldy
From ee63833c5f56064ef47c2bb9debd485f77d00171 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Tue, 19 Mar 2024 18:04:55 +0100
Subject: [PATCH] Move get_bitmask_from_range out of irange class.
---
gcc/value-range.cc | 52 +++---
gcc/value-range.h | 1 -
2 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 70375f7abf9..0f81ce32615 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -31,6 +31,30 @@ along with GCC; see the file COPYING3. If not see
#include "fold-const.h"
#include "gimple-range.h"
+// Return the bitmask inherent in a range.
+
+static irange_bitmask
+get_bitmask_from_range (tree type,
+ const wide_int &min, const wide_int &max)
+{
+ unsigned prec = TYPE_PRECISION (type);
+
+ // All the bits of a singleton are known.
+ if (min == max)
+{
+ wide_int mask = wi::zero (prec);
+ wide_int value = min;
+ return irange_bitmask (value, mask);
+}
+
+ wide_int xorv = min ^ max;
+
+ if (xorv != 0)
+xorv = wi::mask (prec - wi::clz (xorv), false, prec);
+
+ return irange_bitmask (wi::zero (prec), min | xorv);
+}
+
void
irange::accept (const vrange_visitor &v) const
{
@@ -1832,31 +1856,6 @@ irange::invert ()
verify_range ();
}
-// Return the bitmask inherent in the range.
-
-irange_bitmask
-irange::get_bitmask_from_range () const
-{
- unsigned prec = TYPE_PRECISION (type ());
- wide_int min = lower_bound ();
- wide_int max = upper_bound ();
-
- // All the bits of a singleton are known.
- if (min == max)
-{
- wide_int mask = wi::zero (prec);
- wide_int value = lower_bound ();
- return irange_bitmask (value, mask);
-}
-
- wide_int xorv = min ^ max;
-
- if (xorv != 0)
-xorv = wi::mask (prec - wi::clz (xorv), false, prec);
-
- return irange_bitmask (wi::zero (prec), min | xorv);
-}
-
// Remove trailing ranges that this bitmask indicates can't exist.
void
@@ -1978,7 +1977,8 @@ irange::get_bitmask () const
// in the mask.
//
// See also the note in irange_bitmask::intersect.
- irange_bitmask bm = get_bitmask_from_range ();
+ irange_bitmask bm
+= get_bitmask_from_range (type (), lower_bound (), upper_bound ());
if (!m_bitmask.unknown_p ())
bm.intersect (m_bitmask);
return bm;
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 9531df56988..dc5b153a83e 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -351,7 +351,6 @@ private:
bool varying_compatible_p () const;
bool intersect_bitmask (const irange &r);
bool union_bitmask (const irange &r);
- irange_bitmask get_bitmask_from_range () const;
bool set_range_from_bitmask ();
bool intersect (const wide_int& lb, const wide_int& ub);
--
2.44.0
From 03c70de43177a97ec5e9c243aafc798c1f37e6d8 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Wed, 20 Mar 2024 06:25:52 +0100
Subject: [PATCH] Implement minimum prange class exhibiting VRP slowdown.
---
gcc/value-range-pretty-print.cc | 25 +++
gcc/value-range-pretty-print.h | 1 +
gcc/value-range.cc | 274
gcc/value-range.h | 196 +++
4 files changed, 496 insertions(+)
diff --git a/gcc/value-range-pretty-print.cc b/gcc/value-range-pretty-print.cc
index c75cbea3955..154253e047f 100644
--- a/gcc/value-range-pretty-print.cc
+++ b/gcc/value-range-pretty-print.cc
@@ -113,6 +113,31 @@ vrange_printer::print_irange_bitmasks (const irange &r) const
pp_string (pp, p);
}
+void
+vrange_printer::visit (const prange &r) const
+{
+ pp_string (pp, "[prange] ");
+ if (r.undefined_p ())
+{
+ pp_string (pp, "UNDEFINED");
+ return;
+}
+ dump_generic_node (pp, r.type (), 0
Re: [PATCH] Fix rust on *-w64-mingw32
Hello,
Thanks a lot for the patch :)
I agree with Jakub that we should be using the GNU coding style in our
call to std::replace - this is what we try to enforce in the rest of the
Rust frontend.
Regarding the changes to `mkdir_wrapped`, the function now looks a bit odd:
void
mkdir_wrapped (const std::string &dirname)
{
int ret;
ret = mkdir (dirname.c_str (), 0775);
(void) ret;
}
could you change it to something simpler like simply ignoring the return
value of `mkdir`? since this is what we are already doing (and we should
improve error handling here... but one battle at a time).
I would suggest the following:
void
mkdir_wrapped (const std::string &dirname)
{
mkdir (dirname.c_str (), 0775);
}
Have you run the testsuite on *-w64-mingw32? I'm wondering if commenting
out the `register_callback` function causes any issues there?
All in all I'm in favor of this patch, and thanks for submitting it :)
Best,
Arthur
GCC 14.0.1 Status Report (2023-04-26)
Status == We have reached zero P1 regressions today and releases/gcc-14 branch has been created. GCC 14.1-rc1 will be built likely on Tuesday. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. If no show stoppers appear, we'd like to release 14.1 around May 7th, or soon after that, if any important issues are discovered and fixed, rc2 could be released next week. Quality Data Priority # Change from last report --- --- P10- 14 P2 606+ 100 P3 57- 187 P4 219- 9 P5 25- 1 --- --- Total P1-P3 663- 101 Total 907- 111 Previous Report === https://gcc.gnu.org/pipermail/gcc/2024-March/243407.html
GCC 15.0.0 Status Report (2024-04-26)
Status == The trunk has branched for the GCC 14 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 14 so it is possible to test important fixes for 14.1 on it. Quality Data Priority # Change from last report --- --- P16- 8 P2 607+ 101 P3 58- 186 P4 219- 9 P5 25- 1 --- --- Total P1-P3 671- 93 Total 915- 103 Previous Report === https://gcc.gnu.org/pipermail/gcc/2024-March/243407.html
GCC testing on FreeBSD
Hi Gerald, Andreas, How are you testing on FreeBSD? When I build GCC trunk on FreeBSD 14.0 and try to run the libstdc++ testsuite it fails due to lots of these errors: Excess errors: /usr/local/bin/ld: /tmp//ccev946q.o: relocation R_X86_64_32 against symbol `_ZTIN10__cxxabiv115__forced_unwindE@@CXXABI_1.3.2' can not be used when making a PDE object; recompile with -fPIE /usr/local/bin/ld: failed to set dynamic section sizes: bad value Which suggests that -fPIE is missing from the default test flags. Have you seen this? Do you do something locally to work around it? Thanks, Jonathan
Re: [PATCH] Fix rust on *-w64-mingw32
在 2024-04-26 18:47, Arthur Cohen 写道: Hello, Thanks a lot for the patch :) I agree with Jakub that we should be using the GNU coding style in our call to std::replace - this is what we try to enforce in the rest of the Rust frontend. Please feel welcome to rewrite the patch as necessary. It was sent only for illustration about the build issues. could you change it to something simpler like simply ignoring the return value of `mkdir`? since this is what we are already doing (and we should improve error handling here... but one battle at a time). I don't know why there is such a function. It might be better to just replace it with direct calls to `mkdir()`. Have you run the testsuite on *-w64-mingw32? I'm wondering if commenting out the `register_callback` function causes any issues there? No. I only bootstrapped GCC itself with Rust enabled. I know nothing about Rust. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature
gcc-13-20240426 is now available
Snapshot gcc-13-20240426 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20240426/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision 28b3b8a2fe55521a43f3710cf6ced1ab63f1ea03 You'll find: gcc-13-20240426.tar.xz Complete GCC SHA256=aa1c3e69c40cbb8a4a0e5767baf70bb9c72c0115dda9ae13fa6c668b647da205 SHA1=7c210cfe3b4be3b5f407fdf2eb77ae20b7c14e81 Diffs from 13-20240420 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
