Re: Profiling Ada binaries

[rieachus@comcast.net]

On Monday, August 1, 2016 at 7:36:45 PM UTC-4, Jeffrey R. Carter wrote:

> If you look at the requirements for the Cos function in Annex A and Annex G (if
> implemented, which it is for GNAT), you'll find a number of requirements for
> accuracy and special cases. If you look at the definition of the built-in
> function, you'll likely find that it doesn't meet all of those requirements. Any
> call to Cos has to involve wrapping a call to the built-in function in code to
> ensure those requirements are met, so you won't find a call to the built-in
> function in the generated code.

Yes, any "strict" LRM matching implementation probably won't use the built-in functions.  The problem is not the one parameter (radian) versions, it is the two-parameter versions, especially the cases where Ada provides two parameter versions of the arc- (reverse) trig functions.  The problem is not the special case values, but testing for the two parameter versions.  Where "all cases" requires just 2^32 tests, no big deal and I have tests for those.  Two 32-bit parameters is tough, but actually can be done for some functions.  Two 64-bit parameters?  Forget about it.  You have 2^128 cases, which will take about 10^24 CPU years.

Providing a non-strict implementation is much easier.  I don't have to special case the exact cases, and while I would test a decent subset of the full parameter space to to compute mean LSB error statistics, I wouldn't look for special cases.  (Years ago someone -- was it Mike Woodger? -- found FOUR cases where X*X*X*X is not equal to (X*X)*(X*X) for floating point values.  This is why the strict mode should only be used if you really need it. ;-)