Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Paul A. Clayton" <paaronclayton@gmail.com>
Newsgroups: comp.arch
Subject: Re: YASV (Yet Another Security Vulnearability)
Date: Tue, 30 Jul 2024 21:45:43 -0400
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <v8c509$19dpt$1@dont-email.me>
References: <v7rqbf$1ta84$1@dont-email.me> <20240725104113.000006e8@yahoo.com>
 <tJtoO.87238$BYv6.980@fx09.iad> <2024Jul26.181750@mips.complang.tuwien.ac.at>
 <hFToO.27997$iptd.11865@fx36.iad>
 <4a5db46ac6e0d485c3303cca4ccdf77e@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 31 Jul 2024 03:45:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="388c805003a8786b58b0d18617548e60";
	logging-data="1357629"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18p9Lx3oGK+uniBxqB9e5PDUhtjkEnejyg="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.0
Cancel-Lock: sha1:PH9di1j90N2sTXyusDvMCDGr9mc=
In-Reply-To: <4a5db46ac6e0d485c3303cca4ccdf77e@www.novabbs.org>
Bytes: 3466

On 7/26/24 4:53 PM, MitchAlsup1 wrote:
> On Fri, 26 Jul 2024 20:27:04 +0000, EricP wrote:
[snip]>>                                                  Because 
if you
>> retain
>> the predictor values then the new thread has to unlearn what it 
>> learned,
>> before it starts to learn values for the new thread. Whereas if the
>> predictor is flushed it can immediately learn its own values.
> 
> The BP only has 4-states as 2-bits, anything you initialize its state
> to will take nearly as long to seed as a completely random table one
> inherits from the previous process. {{BTBs are different}}

The TA in TAGE is for TAgged; TAGE-based direction preditors would
(I suspect) typically "miss" rather than mispredict. (The papers
on TAGE seem to recommend 3 bit counters; one would expect
correlations to be less strong so averaging over more encounters
seems sensible.)

One can also theoretically alter the sense of a prediction state
or the hysteresis by XORing with other data. XORing a hysteresis
bit with one bit derived from the branch address might have a
beneficial effect on interference. (Agree prediction can also
change the sense of a predictor bit. For the hysteresis bit, if
it is not used for a quick confidence estimate, the backward/
forward character of the static branch could be used to bias the
hysteresis. This might not actually be useful, but is an
obvious design possibility.) I do not know how much such would
affect retraining. Inverting the hysteresis bit sense for half
of the aliasing branches would seem to speed retraining when the
hysteresis is commonly "strongly" (half of aliases would be
interpreted as "weakly")

(Awareness of a phase change, e.g., from increase in misprediction
rate or cache miss rate, might be used to bias retraining or
perhaps bias predictor selection.)

A branch predicted as taken but lacking a BTB entry might use the
BTB miss to rebias the prediction; one would also have the time
between BTB miss determination and decode (for IP-relative
branches) to consult an overriding predictor, either fetching as
if not taken or stalling fetch to save energy.