From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F0CDD3858D38; Sun, 28 May 2023 21:37:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F0CDD3858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685309823; bh=LgrKvFvNQ3jL1Q+1HxHvzbwbHzifZCrlpSF+cLMsIMQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EHkk4fXO24B+HFEYZoJB0sKZqhcJrdgzDL1gbxUWWZhBzHUh+t4fWjOyIykDZ/DbZ NjEHi2i2llnKJ3uNjcAMAtpopMNrxJL2rHenGbyEuAZJnq20oYVXyJZ2vXxYdNvlhi L1qyrvyvogU2jyvGKdhR3lJXJAPLo6Cvt6GEmeXY= From: "richard.yao at alumni dot stonybrook.edu" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyBjLzExMDAwN10gSW1wbGVtZW50IHN1cHBvcnQgZm9yIENs?= =?UTF-8?B?YW5n4oCZcyBfX2J1aWx0aW5fdW5wcmVkaWN0YWJsZSgp?= Date: Sun, 28 May 2023 21:37:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: richard.yao at alumni dot stonybrook.edu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110007 --- Comment #8 from Richard Yao = --- (In reply to Alexander Monakov from comment #6) > Are you sure the branch is unpredictable in your micro-benchmark? If you > have repeated runs you'll train the predictors. (In reply to Jan Hubicka from comment #7) > Also note that branch predicted with 50% outcome is not necessarily > unpredictable for example in this: >=20 > for (int i =3D 0; i < 10000; i++) > if (i&1) > .... >=20 > I would expect branch predictor to work this out on modern systems. > So having explicit flag in branch_probability that given probability is h= ard > for CPU to predict would make sense and I was thinking we may try to get > this info from auto-fdo eventually too. Good point. I had reused an existing micro-benchmark, but it is using libc's srand(), which is known for not having great quality RNG. It is quite possi= ble that the last branch really is predictable because of that. Having only 1 unpredictable branch is not that terrible, so I probably will defer looking into this further to a future date. (In reply to Alexander Monakov from comment #6) > Implementing a __builtin_branchless_select would address such needs more > directly. There were similar requests in the past, two of them related to > qsort and bsearch, unsurprisingly: PR 93165, PR 97734, PR 106804. As a developer that works on a project that supports GCC and Clang equally,= but must support older versions of GCC longer, I would like to see both GCC and Clang adopt each others' builtins. That way, I need to implement fewer compatibility shims to support both compilers and what compatibility shims = I do need can be dropped sooner (maybe after 10 years). I am not against the new builtin, but I would like to also have __builtin_unpredictable(). It would be consistent with the existing likely/unlikely macros that my project uses, which should mean other develo= pers will not have to learn the specifics of how predication works to read code using it, since they can just treat it as a compiler hint and read things a= s if it were not there unless they have some reason to reason more deeply about things. I could just do a macro around __builtin_expect_with_probability(), but I greatly prefer __builtin_unpredictable() since people reading the code do n= ot need to decipher the argument list to understand what it does since the nam= e is self documenting.=