[Bug c/26367] New: multiple levels of __builtin_expect

[Bug c/26367] New: multiple levels of __builtin_expect

[acahalan at gmail dot com]

My expectation may be:

a. certain (OK if the code crashes when I lie)
b. strong
c. weak

This could be expressed as an optional 3rd argument to state the estimated
probability. Alternately, stuff like __builtin_expect_strongly() could be used.

I'd like to use this to inform gcc that certain bit patterns or value ranges
are impossible. The main hope is that gcc can optimize switch() better by
letting all the can't-happen cases do undefined behavior. Math should be better
too, for example not needing to worry about the sign bit (more instruction
choice, etc.) if I tell gcc that it will never be set.


-- 
           Summary: multiple levels of __builtin_expect
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: acahalan at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367

[Bug c/26367] multiple levels of __builtin_expect

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-20 02:15 -------
Can you give an example of why you need these builtins?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367

[Bug c/26367] multiple levels of __builtin_expect

[acahalan at gmail dot com]

------- Comment #2 from acahalan at gmail dot com  2006-02-20 03:49 -------
I gave two examples. (you may assume I want code to run fast)

I first saw this feature proposed on the linux-kernel mailing list when there
was some argument over whether or not __builtin_expect() should be used in a
particular location. For one architecture it was good (i386 if I remember
right), but for another architecture (ARM if I remember right) it was bad. The
problem is that the behavior change is appropriate at X% likelyhood on one
architecture, and Y% likelyhood on a different architecture. X and Y are not
documented.

So somebody wished that __builtin_expect() would take an argument to specify
probability. I agree.

For each change of compiler behavior (setting an instruction bit, moving code
out of line, making unlikely code as if -Os were specified...) there is an
architecture-specific probability level at which it makes sense.

A more awkward way to expose this would be as a predefined preprocessor symbol
that specifies the architecture-specific likelyhood at which __builtin_expect()
may be useful. It's a bit nicer to just let the programmer give a 3rd argument.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367

[Bug c/26367] multiple levels of __builtin_expect

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-20 03:51 -------
Oh, did I forgot __builtin_expect gives the same probability on all targets,
just some use it more than others.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367

[Bug c/26367] multiple levels of __builtin_expect

[acahalan at gmail dot com]

------- Comment #4 from acahalan at gmail dot com  2006-02-20 04:11 -------
It's interesting that you say "__builtin_expect gives the same probability on
all targets". I'm not exactly sure what you mean, but I'll guess that you mean
it states that the condition will be true X% of the time.

If so, X should be documented. Also: approximately X% or minimum X%?

BTW, it seems that this X value might not be correct for all architectures. I
guess that would be a different bug though, and the problem may have been fixed
by now.

It would be nice to have more than one level, including at least "100% certain"
and two other levels.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367

[Bug c/26367] multiple levels of __builtin_expect

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2006-02-21 10:03 -------
With exception to 'certain' this doesn't really make sense.  And the 'certain'
one
should be called __builtin_assert().  But then, VRP or DOM might already
extract information from

  if (x == 0)
    abort();
  return x;

(no, neither 4.1 nor mainline can do this ATM).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367

[Bug c/26367] multiple levels of __builtin_expect

[acahalan at gmail dot com]

------- Comment #6 from acahalan at gmail dot com  2006-02-22 03:18 -------
I don't think it is legit to extract any sort of certainty from this:

  if (x == 0)
    abort();
  return x;

There may be a SIGABRT handler which allows the program to live.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367

[Bug c/26367] multiple levels of __builtin_expect

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed when __builtin_expect_with_probability was added which was recorded as PR
83610.

https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect_005fwith_005fprobability


So closing as a dup.

*** This bug has been marked as a duplicate of bug 83610 ***

[Bug c/26367] multiple levels of __builtin_expect

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-12-22 01:21:00 UTC ---
I think __builtin_unreachable resolved some of this already.  Also probilities
to noreturn functions are marked as notlikely already.