Tobias Burnus wrote:
Sandra Loosemore wrote:
FWIW, though, my preference would be to replace these two options with
a single option that takes an argument, like -fopenmp-ompt=none,
-fopenmp-ompt=basic, and -fopenmp-ompt=details, and -fopenmp-ompt
being a synonym for -fopenmp-ompt=basic, and -fno-openmp-ompt for
-fopenmp-ompt=none -- especially if more kinds of tracing or
finer-grained control are anticipated in the future.
I don't think that we will see finer control. The idea is:
-fopenmp
add no additional runtime calls but have a decent OMPT support
-fopenmp -fopenmp-ompt
Additional calls that have a low overhead but a larger benefit
Namely: instead of telling the tool only when something begins,
also tell it when it ends.
-fopenmp -fopenmp-ompt-detailed
Add more expensive calls, usually not needed but if one really
wants to drill down and does not fear a higher overhead
And I have a hard time imagine an additional option here.
Otherwise, I think combining the two and supporting
(-fno-openmp-ompt )
-fopenmp-ompt
-fopenmp-ompt=detailed
would look better in the documentation than having two
separate options.
However, the -fopenmp-ompt=basic and -fopenmp-ompt=none
are a bit odd:
-fopenmp-ompt=none in particular but also -fno-openmp-ompt
are a bit strange as - despite 'none' / 'no' - OMPT is still
mostly handled, just some additional details aren't reported
to the tool.
Likewise, -fopenmp=basic is not the minimal support, even if
'basic' implies this but already provides something extra,
albeit less than with 'detailed'.
* * *
I am fine with combing the two options into one - but I am not
planing to implement it.
(On the bike-shedding side: basic, extended, detailed
would also work, albeit basic == -fno-openmp-ompt looks odd.
And extended vs. detailed has no clear ordering regarding
which provides more data and whether one includes the other or
not.)
I am happy to implement an improved version of the -fopenmp-ompt option
but I would like to reach consensus before actually writing a patch.
*What about the following*
Having a single option still called '-fopenmp-ompt' that takes an
argument. Possible values would be 'minimal' (default), 'basic' and
'extended'. Make it RejectNegative to disallow -fno-openmp-ompt.
-fopenmp implies -fopenmp-ompt[=minimal]. -fopenmp-ompt still requires
-fopenmp (no change).
*Rationale*
In GCC, OMPT is implemented in three tiers, hence three possible values
for the argument. But it is not possible to completely opt out, hence
'minimal' rather than 'none', and RejectNegative as -fno-openmp-ompt
does not make sense.
What do you think?
--
PA
