On Tue, 9 Apr 2024, Jason Merrill wrote:
> On 2/16/24 10:06, Patrick Palka wrote:
> > On Thu, 15 Feb 2024, Patrick Palka wrote:
> >
> > > One would expect consecutive calls to bytes_in/out::b for streaming
> > > adjacent bits, as we do for tree flag streaming, to at least be
> > > optimized by the compiler into individual bit operations using
> > > statically known bit positions (and ideally merged into larger sized
> > > reads/writes).
>
> Did you have any thoughts about how feasible it would be to use
> data-streamer.h? I didn't see a response to richi's mail.
IIUC the workhorses of data-streamer.h are
for streaming out: bitpack_create / bp_pack_value / streamer_write_bitpack
for streaming in: streamer_read_bitpack / bp_unpack_value
which use a locally constructed bitpack_d struct for state management,
much like what this patch proposes, which is a sign that this is a good
approach I suppose.
The bit twiddling code is unsurprisingly pretty similar except
data-streamer.h can stream more than one bit at a time whereas
bits_in/out::b from this patch can only handle one bit at a time
(which is by far the common case). Another difference is that the
data-streamer.h buffer is a HOST_WIDE_INT while the modules bit buffer
is uint32_t (this patch doesn't change that).
Unfortunately it seems data-streamer.h is currently hardcoded for
LTO streaming since bitpack_d::stream must be an lto_input_block and it
uses streamer_write_uhwi_stream and streamer_read_uhwi under the hood.
So we can't use it for modules streaming currently without abstracting
away this hardcoding AFAICT.
>
> > > Unfortunately this doesn't happen because the compiler has trouble
> > > tracking the values of this->bit_pos and this->bit_val across such
> > > calls, likely because the compiler doesn't know 'this' and so it's
> > > treated as global memory. This means for each consecutive bit stream
> > > operation, bit_pos and bit_val are loaded from memory, checked if
> > > buffering is needed, and finally the bit is extracted from bit_val
> > > according to the (unknown) bit_pos, even though relative to the previous
> > > operation (if we didn't need to buffer) bit_val is unchanged and bit_pos
> > > is just 1 larger. This ends up being quite slow, with tree_node_bools
> > > taking 10% of time when streaming in parts of the std module.
> > >
> > > This patch optimizes this by making tracking of bit_pos and bit_val
> > > easier for the compiler. Rather than bit_pos and bit_val being members
> > > of the (effectively global) bytes_in/out objects, this patch factors out
> > > the bit streaming code/state into separate classes bits_in/out that get
> > > constructed locally as needed for bit streaming. Since these objects
> > > are now clearly local, the compiler can more easily track their values.
>
> Please add this rationale to the bits_in comment.
Will do.
>
> > > And since bit streaming is intended to be batched it's natural for these
> > > new classes to be RAII-enabled such that the bit stream is flushed upon
> > > destruction.
> > >
> > > In order to make the most of this improved tracking of bit position,
> > > this patch changes parts where we conditionally stream a tree flag
> > > to unconditionally stream (the flag or a dummy value). That way
> > > the number of bits streamed and the respective bit positions are as
> > > statically known as reasonably possible. In lang_decl_bools and
> > > lang_type_bools we flush the current bit buffer at the start so that
> > > subsequent bit positions are statically known. And in core bools, we
> > > can add explicit early exits utilizing invariants that the compiler
> > > can't figure out itself (e.g. a tree code can't have both TS_TYPE_COMMON
> > > and TS_DECL_COMMON, and if a tree code doesn't have TS_DECL_COMMON then
> > > it doesn't have TS_DECL_WITH_VIS). Finally if we're streaming fewer
> > > than 4 bits, it's more space efficient to stream them as individual
> > > bytes rather than as packed bits (due to the 32-bit buffer).
> >
> > Oops, this last sentence is wrong. Although the size of the bit buffer
> > is 32 bits, upon flushing we rewind unused bytes within the buffer,
> > which means streaming 2-8 bits ends up using only one byte not all four.
> > So v2 below undoes this pessimization.
> >
> > > This patch also moves the definitions of the relevant streaming classes
> > > into anonymous namespaces so that the compiler can make more informed
> > > decisions about inlining their member functions.
>
> I'm curious why you decided to put namespace { } around each class rather than
> a larger part of the file? Not asking for a change, just curious.
I don't feel strongly about i, but to me using a separate namespace { }
for each class is consistent with how we use 'static' instead of
namespace { } to give (consecutively defined) free functions internal
linkage, i.e. instead of
namespace {
void f() { }
void g() { }
}
we do
static void f() { }
static void g() { }
Using a separate namespace { } for each class is the closest thing to
'static' for types. And it makes it obvious whether a class is TU-local
or not.
>
> I'm also surprised that this would make a difference for inline functions? Is
> this just to allow the compiler to inline member functions defined outside the
> class body without marking them inline?
The motivation was initially to help ensure trees_in/out::core_bools,
::lang_type_bools and ::lang_decl_bools get inlined into their only
caller ::tree_node_bools. This is crucial because these functions take
bits_in/out parameters by reference and if they're not inlined then the
compiler can't track the bit state, and we generate bad code again with
a buffering check after every single bit read/write.
Only by giving them internal linkage can the compiler see they have just
one caller, which guarantees they get inlined. They're otherwise fairly
large functions which are not clearly profitable to inline.
And I reckoned it's good code hygiene to give TU-local types internal
linkage much like how we declare TU-local free functions 'static' so
I gave the base classes of trees_in/out internal linkage as well.
>
> In any case, please add a rationale comment to the (first) anonymous
> namespace.
Sure, I opted to add a rationale to trees_in since it and trees_out are
the classes that most benefit from this change.
>
> > > After this patch, compile time for a simple Hello World using the std
> > > module is reduced by 7% with a release compiler. The on-disk size of
> > > the std module increases by 0.7% (presumably due to the extra flushing
> > > done in lang_decl_bools and lang_type_bools).
> >
> > The on-disk std module now only grows 0.4% instead of 0.7%.
> > >
> > > The bit stream out performance isn't improved as much as the stream in
> > > due to the spans/lengths instrumentation performed on stream out (which
> > > probably should be e.g. removed for release builds?)
>
> Based on CHECKING_P, sure.
I can do that in a follow-up patch.
>
> > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > index 0291d456ff5..2ecee007e8a 100644
> > --- a/gcc/cp/module.cc
> > +++ b/gcc/cp/module.cc
> > @@ -694,13 +656,126 @@ protected:
> > /* Instrumentation. */
> > static unsigned spans[4];
> > static unsigned lengths[4];
> > - static int is_set;
> > + friend struct bits_out;
> > };
> > +} // anon namespace
> > +
> > +/* Finish bit packet. Rewind the bytes not used. */
>
> Missing blank line.
Fixed.
>
> > +static unsigned
> > +bit_flush (data& bits, uint32_t& bit_val, unsigned& bit_pos)
> > +{
> > + gcc_assert (bit_pos);
> > + unsigned bytes = (bit_pos + 7) / 8;
> > + bits.unuse (4 - bytes);
> > + bit_pos = 0;
> > + bit_val = 0;
> > + return bytes;
> > +}
> > +
> > @@ -5314,6 +5326,8 @@ trees_out::core_bools (tree t)
> > if (TREE_CODE_CLASS (code) != tcc_type)
> > /* This is TYPE_CACHED_VALUES_P for types. */
> > WB (t->base.public_flag);
> > + else
> > + WB (false);
>
> Can we simplify the pattern for conditionally writing/reading? It looks easy
> to forget to add the else. Perhaps a COND_WB macro with rationale comment?
Fixed.
Here's an incremental diff of the changes. Will send updated patch as a
follow-up email.
-- >8 --
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index cb3803a6a12..765d7dde715 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -661,6 +661,7 @@ protected:
} // anon namespace
/* Finish bit packet. Rewind the bytes not used. */
+
static unsigned
bit_flush (data& bits, uint32_t& bit_val, unsigned& bit_pos)
{
@@ -679,7 +680,12 @@ bit_flush (data& bits, uint32_t& bit_val, unsigned&
bit_pos)
When reading, we don't know how many bools we'll read in. So read
4 bytes-worth, and then rewind when flushing if we didn't need them
all. You can't have a block of bools closer than 4 bytes to the
- end of the buffer. */
+ end of the buffer.
+
+ Both bits_in and bits_out maintain the necessary state for bit packing,
+ and since these objects are locally constructed the compiler can more
+ easily track their state across consecutive reads/writes and yield
+ optimized code with a minimal number of buffering checks. */
namespace {
struct bits_in {
@@ -2839,7 +2845,11 @@ struct post_process_data {
/* Tree stream reader. Note that reading a stream doesn't mark the
read trees with TREE_VISITED. Thus it's quite safe to have
multiple concurrent readers. Which is good, because lazy
- loading. */
+ loading.
+
+ It's important that trees_in/out have internal linkage so that the compiler
+ knows core_bools, lang_type_bools and lang_decl_bools have only a single
+ caller (tree_node_bools) and inlines them appropriately. */
namespace {
class trees_in : public bytes_in {
typedef bytes_in parent;
@@ -5282,6 +5292,10 @@ void
trees_out::core_bools (tree t, bits_out& bits)
{
#define WB(X) (bits.b (X))
+/* Stream X if COND holds, and if !COND stream a dummy value so that the
+ overall number of bits streamed is independent of the runtime value
+ of COND, which allows the compiler to optimize this function better. */
+#define COND_WB(COND, X) WB ((COND) ? (X) : false)
tree_code code = TREE_CODE (t);
WB (t->base.side_effects_flag);
@@ -5298,11 +5312,8 @@ trees_out::core_bools (tree t, bits_out& bits)
decls they use. */
WB (t->base.nothrow_flag);
WB (t->base.static_flag);
- if (TREE_CODE_CLASS (code) != tcc_type)
- /* This is TYPE_CACHED_VALUES_P for types. */
- WB (t->base.public_flag);
- else
- WB (false);
+ /* This is TYPE_CACHED_VALUES_P for types. */
+ COND_WB (TREE_CODE_CLASS (code) != tcc_type, t->base.public_flag);
WB (t->base.private_flag);
WB (t->base.protected_flag);
WB (t->base.deprecated_flag);
@@ -5499,6 +5510,8 @@ bool
trees_in::core_bools (tree t, bits_in& bits)
{
#define RB(X) ((X) = bits.b ())
+/* See the comment for COND_WB in trees_out::core_bools. */
+#define COND_RB(COND, X) ((COND) ? RB (X) : bits.b ())
tree_code code = TREE_CODE (t);
@@ -5513,10 +5526,7 @@ trees_in::core_bools (tree t, bits_in& bits)
/* base.used_flag is not streamed. */
RB (t->base.nothrow_flag);
RB (t->base.static_flag);
- if (TREE_CODE_CLASS (code) != tcc_type)
- RB (t->base.public_flag);
- else
- bits.b ();
+ COND_RB (TREE_CODE_CLASS (code) != tcc_type, t->base.public_flag);
RB (t->base.private_flag);
RB (t->base.protected_flag);
RB (t->base.deprecated_flag);
