Idea: Optionally count share of subnormal inputs sent to each instruction type

[HadrienG2]

Recently, as part of the Gray-Scott school's webinar series, I've been reporting on my ongoing studies of the performance impact of subnormals on various CPU models. See attached talk slides.

After the talk, a colleague asked me whether we could roughly estimate the impact of subnormals on a particular program execution (program + input configuration) by measuring the share of subnormal inputs sent to each type of machine operation and using my performance measurements as a performance model for a particular hardware.

It seemed to me like Verrou could potentially measure the share of subnormal inputs, since it's able to instrument every FP instruction in the program. The question is, how hard would it be on your side?

[lathuili]

Thanks for sharing your slides: they are really interesting.

For a proof of concept, I think it is easily doable. For a clean integration it is more work and requires more thought:

• The type in the backend (Interflop interface) is not exactly the same as the type in the frontend. The subnormal detection should be done in a new backend. But I think the user might want to keep the frontend definition to be consistent with counter.

• What to do with libm? Instrument libm or instructions within libm?

• Is there any interest in being compatible with other rounding modes?

I'm not sure I understand the context. To estimate the computation time wasted by subnormals, I usually compile my code with FTZ flags to see if I reduce the computation time. When the code fails with FTZ, I do a delta-debug with --rounding-mode=ftz to understand why and to fix the code. This approach doesn't work for code that contains sections that really need subnormal. If this is your case, I hope you have permission to share this application.