On Fri, Apr 26, 2024 at 11:45 AM Aldy Hernandez via Gcc <gcc@gcc.gnu.org> wrote: > > 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.
You can use -Winline to see why we don't inline an inline declared function. I would guess the unit-growth limit kicks in? Did you check a release checking compiler? That might still inline things. > 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