GNU bug report logs - #54532
Faster sorting

Previous Next

Full log

Message #38 received at 54532 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acohen <at> ust.hk, 54532 <at> debbugs.gnu.org
Subject: Re: bug#54532: [PATCH] sorting
Date: Thu, 24 Mar 2022 10:36:49 +0100

24 mars 2022 kl. 07.42 skrev Eli Zaretskii <eliz <at> gnu.org>:

> That instance was
> at the end of the function, right before it returns, and I wonder what
> kind of optimization opportunities that could present.

I don't think we need to justify every single `eassume` on the concrete utility for a compiler; in general, the more information we give it, the better code it can produce. It just doesn't hurt to do so.

In fact, the only reason we have `eassert` at all is for assertions that may be time-consuming or otherwise affect the execution (that is, expressions that the compiler just can't optimise away). For anything else, `eassume` is strictly better since it does all that `eassert` does, but with the extra optimisation hints.

Now in this concrete case, we state that `lastofs` and `ofs` are equal at the point when we are about to return `ofs`, and that gives the compiler the option to return `lastofs` instead, should that be more convenient in some way.

The compiler also knows that lastofs >= ofs because of the loop condition, which means that it can deduce that lastofs > ofs can never occur which can have various uses -- for example, in the statement

      ptrdiff_t m = lastofs + ((ofs - lastofs) >> 1);

it would know that the argument being shifted is nonnegative, which might be useful in instruction selection. And so on.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.