Robert Finch <robfi680@gmail.com> writes:I had little trouble teaching Brian how to put if-conversion into theHaving branches automatically convert into>
predicates when they branch forward a short distance <7 instructions.
If-conversion in hardware is a good idea, if done well, because it
involves issues that tend to be unknown to compilers:
compiler with my PRED instructions. Alleviating HW from having to bother
other than being able to execute PREDicated clauses.
* How predictable is the condition? If the condition is very wellRather than base the choice on the predictability of the condition,
predictable, if-conversion is not a good idea, because it turns the
control dependency (which does not cost latency when the prediction
is correct) into a data dependency. Moreover, in this case the
if-conversion increases the resource consumption. Compilers are not
good at predicting the predictability AFAIK.
It is based on whether FETCH will pass the join-point before the
condition resolves. On an 8-wide machine this might be "THE next
cycle".
* Is the condition available before or after the original dataGenerally, it only adds latency--if the execution window is not staled
dependencies? And if afterwards, by how many cycles? If it is
afterwards and the branch prediction would be correct, the
if-conversion means that the result of the instruction is available
later, which may reduce IPC.
at either end this does not harm IPC.
OTOH, if the branch prediction wouldThere is no "recovery" from PREDication, just one clause getting
be incorrect, the recovery also depends on when the condition
becomes available,
nullified.
and the total latency is higher in the case of noMy argument is that this is a SW decision (in the compiler) not a
if-conversion. The compiler may do an ok job at predicting whether
a condition is available before or after the original data
dependencies (I don't know a paper that evaluates that), but without
knowing about the prediction accuracy of a specific condition that
does not help much.
>
So the hardware should take predictability of a condition and the
availability of the condition into consideration for if-conversion.
HW decision (other than providing the PREDs). Since PREDs are not
predicted (unless you think they are predicted BOTH ways) they do
not diminish the performance of the branch predictors.
What about reverse if-conversion in hardware, i.e., convertingThe compiler choose PRED because FETCH reaches the join-point prior
predicated instructions and the like (conditional moves, if-then-else
instructions and the instructions they control) into branch-predicted
phantom branches and eliminating the data dependency on the condition
from the instruction.
to the branch resolving. PRED is almost always faster--and when
it has both then-clause and else-clause, it always saves a branch
instruction (jumping over the else-clause).
For performance, one might consider reverse if-conversion, because the
same considerations apply; however, there is also a security aspect:
programmers have used these instructions instead of branches to
produce constant-time code to avoid timing side channels of code that
deals with secrets; and the discovery of Spectre has shown additional
timing side channels of branches. Because you cannot be sure that the
predicated instruction is there for security reasons, you must not use
reverse if-conversion in hardware.
>
- anton
| Date | Sujet | # | Auteur | |
| 17 Apr 25 |  Re: register sets | 56 | Robert Finch | |
| 17 Apr 25 |  Re: register sets | 53 | Stephen Fuld | |
| 17 Apr 25 |   Re: register sets | 1 | Robert Finch | |
| 17 Apr 25 | Re: register sets | 46 | MitchAlsup1 | |
| 18 Apr 25 |  Re: register sets | 45 | Robert Finch | |
| 18 Apr 25 |  Re: register sets | 44 | MitchAlsup1 | |
| 20 Apr 25 | Re: register sets | 43 | Robert Finch | |
| 21 Apr 25 | Re: auto predicating branches | 42 | Robert Finch | |
| 21 Apr 25 | Re: auto predicating branches | 41 | Anton Ertl | |
| 21 Apr 25 | Is an instruction on the critical path? (was: auto predicating branches) | 1 | Anton Ertl | |
| 21 Apr 25 | Re: auto predicating branches | 39 | MitchAlsup1 | |
| 22 Apr 25 | Re: auto predicating branches | 38 | Anton Ertl | |
| 22 Apr 25 | Re: auto predicating branches | 1 | MitchAlsup1 | |
| 22 Apr 25 | Re: auto predicating branches | 36 | Anton Ertl | |
| 22 Apr 25 | Re: auto predicating branches | 35 | MitchAlsup1 | |
| 23 Apr 25 | Re: auto predicating branches | 3 | Stefan Monnier | |
| 23 Apr 25 | Re: auto predicating branches | 2 | Anton Ertl | |
| 25 Apr 25 | Re: auto predicating branches | 1 | MitchAlsup1 | |
| 23 Apr 25 | Re: auto predicating branches | 31 | Anton Ertl | |
| 23 Apr 25 | Re: auto predicating branches | 30 | MitchAlsup1 | |
| 24 Apr 25 | Re: asynch register rename | 29 | Robert Finch | |
| 27 Apr 25 | Re: fractional PCs | 28 | Robert Finch | |
| 27 Apr 25 | Re: fractional PCs | 27 | MitchAlsup1 | |
| 28 Apr 25 | Re: fractional PCs | 26 | Robert Finch | |
| 28 Apr 25 | Re: fractional PCs | 15 | MitchAlsup1 | |
| 29 Apr 25 | Re: fractional PCs | 14 | Robert Finch | |
| 5 May 25 | Re: control co-processor | 13 | Robert Finch | |
| 5 May 25 | Re: control co-processor | 12 | Al Kossow | |
| 5 May 25 | Re: control co-processor | 11 | Stefan Monnier | |
| 6 May 25 | Re: control co-processor | 3 | MitchAlsup1 | |
| 7 May 25 | Re: control co-processor | 1 | MitchAlsup1 | |
| 15 Jul 25 | Re: control co-processor | 1 | MitchAlsup1 | |
| 7 May 25 | Scan chains (was: control co-processor) | 7 | Stefan Monnier | |
| 7 May 25 | Re: Scan chains (was: control co-processor) | 2 | Al Kossow | |
| 7 May 25 | Re: Scan chains | 1 | Stefan Monnier | |
| 7 May 25 | Re: Scan chains | 3 | MitchAlsup1 | |
| 7 May 25 | Re: Scan chains | 2 | Stefan Monnier | |
| 8 May 25 | Re: Scan chains | 1 | MitchAlsup1 | |
| 15 Jul 25 | Re: Scan chains | 1 | MitchAlsup1 | |
| 29 Apr 25 | Re: fractional PCs | 10 | Robert Finch | |
| 29 Apr 25 | Re: fractional PCs | 9 | MitchAlsup1 | |
| 30 Apr 25 | Re: fractional PCs | 8 | Robert Finch | |
| 30 Apr 25 | Re: fractional PCs | 6 | Thomas Koenig | |
| 1 May 25 | Re: fractional PCs | 1 | Robert Finch | |
| 2 May 25 | Re: fractional PCs | 4 | moi | |
| 2 May 25 | Re: millicode, extracode, fractional PCs | 2 | John Levine | |
| 2 May 25 | Re: millicode, extracode, fractional PCs | 1 | moi | |
| 2 May 25 | Re: fractional PCs | 1 | moi | |
| 30 Apr 25 | Re: fractional PCs | 1 | MitchAlsup1 | |
| 15 Jul 25 | Re: register sets | 5 | John Savard | |
| 15 Jul 25 | Re: register sets | 4 | MitchAlsup1 | |
| 19 Jul 25 | Re: register sets | 3 | Robert Finch | |
| 19 Jul 25 | Re: register sets | 2 | Anton Ertl | |
| 19 Jul 25 | Re: register sets | 1 | MitchAlsup1 | |
| 15 Jul 25 | Re: register sets | 2 | John Savard | |
| 15 Jul 25 | Re: register sets | 1 | MitchAlsup1 |
Les messages affichés proviennent d'usenet.