Feature request: Documentation updates, and guided optimization beyond ASSUME and LOOP COUNT

[ereisch]

I find using the LOOP COUNT directive very useful in my code base, as it can be used to hint to the compiler the expected range of values a loop iteration variable may have.  However, there are couple additions/modifications that I believe would greatly increase the utility of this directive (and others):

• Update the documentation to indicate the behavior if the MIN and/or MAX values of the LOOP COUNT are violated.  Are there run-time checks to enforce the hinted range?
• Update the documentation for the ASSUME directive to indicate that code elimination will occur if the ASSUME directive indicates this is possible.  In other words, the ASSUME directive is a strictly-enforced assumption (and it does not appear as though a runtime check is emitted to assert if the assumption is violated, unless "-check assume" is specified in the compiler flags).  This is markedly different than the similarly-syntaxed GCC __builtin_expect__(()) compiler directive.  For example, in the following case, code for <SOMETHING> will not be emitted by the compiler:

  !DIR$ ASSUME (N .LT. 5)
  IF ( N .GE. 5 ) THEN
    <SOMETHING>
  END IF​

  ...additionally, it is not clear where/when in the program's execution the check is performed if the flag is set.

• Having a way to globally set an "expected" value (or range of values, similar to the LOOP COUNT directive) for a variable will be of great use.  Right now, ifort (and ifx) apply equal weights for conditional code paths (if you examine the compiler's assembler output, it indicates heuristic probabilities for divergent code paths, and most are 50% if it cannot deduce the range of expected values).  If I have a variable "N" in a subprogram, and I know that its value throughout the subprogram will "almost" always have a minimum of 1, a maximum of 10, and a mean of 2, these assumptions can be carried through not only to DO loops, but to IF statement code generation as well.  Note the "almost" qualifier, as there may be cases where you will want a code path to be assumed near non-existent, but still generated nonetheless; e.g., if a routine was passed invalid values, which should ideally never happen (so its probability for the purpose of heuristics should be near zero), but you want a code path to still exist to trap  this condition.  This is exactly what __builtin_expect__(()) is used for in GCC.
  • I understand profile-guided optimization may provide additional hints to the compiler such as this, but not all programs are structured such that PGO is a feasible solution

Thanks for the compilers!

[jimdempseyatthecove]

>> it is not clear where/when in the program's execution the check is performed if the flag is set.

I presume it would be at the point in the source code where the !DIR$ ASSUME is located.

>>Having a way to globally set an "expected" value (or range of values, similar to the LOOP COUNT directive) for a variable will be of great use.

I would think it would be better to have a locally set an "expected"...

This would require a different keyword, perhaps PRESUME or EXPECT. This would not eliminate code, but rather help the  optimizer to rearrange code. BTW one could (?should?) expressly write the code in an order of preference (you specify filtering order).

Jim Dempsey

[Barbara_P_Intel · Accepted solution]

Thanks for the comments. You're welcome for the compiler.

Regarding LOOP COUNT... the directive is aimed at supplying additional information to the optimizer so it can do a better job of code generation. There is no runtime check.

Regarding ASSUME... How's your wordsmithing? How would you rewrite the description in the Developer Guide?

Regarding the new directive... Given the large amount of effort this would be to implement and because of other priorities, it is unlikely this would be considered for a feature in a near future release.  

[ereisch]

Current:

---

The scalar-Boolean-expression is presumed to be true and may be used by the optimizer to generate better code.

If the "check assume" option is specified and scalar-Boolean-expression does not evaluate to .TRUE. at run time, an error message is displayed and execution is aborted.

---

Proposed alternative:

The scalar-Boolean-expression is presumed to always be true and may be used by the optimizer to generate better code.

If the "check assume" option is specified and scalar-Boolean-expression does not evaluate to .TRUE. at run time, an error message is displayed and execution is aborted.  If the "check assume" option is not specified and scalar-Boolean-expression does not evaluate to .TRUE. at run time, program behavior may be undefined.

---

Commentary about where/when the check is performed (when "check assume" is asserted) would be helpful as well.

[jimdempseyatthecove]

I think and assertion (check assume) would have to be located at the point in the source of the directive. Consider:

if(smallModel) then
  !DIR$ ASSUME (N .LT. 5)
  IF ( N .GE. 5 ) THEN
    <SOMETHING>
  END IF​
else
  !DIR$ ASSUME (N .LT. 50)
  IF ( N .GE. 50 ) THEN
    <SOMETHING>
  END IF​
endif

It would make no sense to move the check assume outside the scope of each IF branch.

Jim Dempsey

[ereisch]

Well, some people may assume (no pun intended) but not all may. Better to be explicit.

And I would actually propose a small change to my previous post:
"The scalar-Boolean-expression is presumed to always be true when execution reaches the directive, and may be used by the optimizer to generate better code."

[Barbara_P_Intel]

I finally confirmed what the compiler does with LOOP COUNT and ASSUME for these cases. I leaned heavily on the wordsmithing on this thread. Thank you. Sorry, but I don't see a way to give by-lines in the Fortran DGR (Developer Guide and Reference).

I filed a bug report to clarify the descriptions, DOC-10191.

[Barbara_P_Intel]

An updated Fortran Developer Guide and Reference has recently been published. The new wording is there clarifying the wording for !DIR$ ASSUME and !DIR$ LOOP COUNT.

Enjoy!