I was looking at some of the assembly output generated by Intel Fortran
"ifort -S file.f" and some annotations caught my eye:

js ..B1.6 # Prob 2%% #35.10
jg ..B1.4 # Prob 18%% #35.10
jmp ..B1.3 # Prob 100%% #
jmp ..B1.5 # Prob 100%% #37.10
jle ..B2.11 # Prob 2%% #188.13

It looks like all the branches in the code have a probability associated
with them. The unconditional branches have 100%% probability (the branch
certainly will get taken), the condition branches have less than 100%%
probability.

So it looks to me like the compiler is trying to do branch prediction,
but how is this information transmitted to the hardware? ISTR that in
the days of Olde Fortran there was a "FREQUENCY" statement that could
provide branch prediction hints to the compiler, but this was dropped
eons ago.

On Thu, 10 Apr 2008 14:38:28 GMT, Charles Coldwell gmail.com> wrote:

It's not.

Well, I would say that the compiler is guessing on its own what the branch
probability is for purpose of optimization. The hardware is not static, it
can take into account actual behavior (if this branch was taken before, it's
likely to be taken again, etc.)

The compiler does flow analysis to determine how to lay out code for
optimization. It uses its own branch prediction, or profile-guided feedback
if available, to make these decisions. It can also affect register allocation
and inlining decisions.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

Charles Coldwell wrote:

It seems that FREQUENCY had two uses. One was for relative
branch frequencies for arithmetic IF and computed GOTO.
The other was a hint at how many times a DO loop would execute.

For nested DO loops the latter would allow optimization based
on the expected number of iterations for each loop.

-- glen

In article gmail.com>,
Charles Coldwell gmail.com> wrote:

I can't speak for the Intel compiler, but lots of compilers can
be convinced to spit out intersting info in their assembly files.
For the Open64/PathScale compiler, they're called "love notes".

Hardware went through several generations of branch prediction, and it
used to be important for compilers to help predict.

Gen1 was "conditional branches predicted taken" (or "not taken",
depending on your architecture). So compilers wanted to
match this static prediction with the most likely action.

Gen2 was "there's a field for a static prediction", so the compiler
had to set the field.

Gen3 was "we have this great new dynamic hardware branch prediction
scheme, and don't need any steenkin' compiler help".

Even in the Gen3 era it's still slightly helpful to generate
straight-line code for the most common case.