On Thu, Nov 10, 2022 at 08:20:06PM +0100, Jakub Jelinek via Gcc-patches wrote:
> So, maybe for now a selftest will be better than a testcase, or
> alternatively a plugin test which acts like a selftest.
For a testsuite/g*.dg/plugin/ range-op-plugin.c test, would be
nice to write a short plugin that does:
1) register 2 new attributes, say gcc_range and gcc_expected_range,
parse their arguments
2) registers some new pass (dunno where it would be best, say before evrp
or so), which would:
- for function parameters with gcc_range attributes set global? range
on default def of that parameter
- if function itself has a gcc_expected_range attribute, propagate
ranges from arguments to the function result and compare against
gcc_expected_range
- if function itself has gcc_range attribute and one of the arguments
gcc_expected_range itself, try to propagate range backwards from
result to the argument
Then we could say write tests like:
__attribute__((gcc_expected_range (12.0, 32.0, 0))) double
foo (double x __attribute__((gcc_range (2.0, 4.0, 0))), double y
__attribute__((gcc_range (6.0, 8.0, 0))))
{
return x * y;
}
with for floating point types (parameter type or function result type)
the arguments of the attribute being (constant folded)
low bound, high bound, integer about NAN (say 0 meaning clear_nan,
bit 0 meaning +NAN, bit 1 -NAN, bit 2 meaning known NAN (then
the 2 bounds would be ignored)).
Eventually we could do something similar for integral types, pointer types
etc.
I think this would be far more useful compared to writing selftests for it,
and compared to the testcase I've posted would be easier to request or check
exact range rather than a rough range. And we could easily
test not just very simple binary ops (in both directions), but builtin calls
etc.
Thoughts on this?
I can try to write a plugin that registers the attributes, parses them
and registers a pass, but would appreciate your or Andrew's help in filling
the actual pass.
Jakub
