This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] simplify-rtx.c: start adding selftests (v2)
On 07/19/2016 09:46 AM, David Malcolm wrote:
It almost seems like the iteration space has to be dependent on what
you're testing. Ie, some tests you want to iterate over the standard
integer modes. Other tests you might reasonably include FP modes.
CC
modes I think should be forbidden for these tests. THere may be
others
to ponder as well.
Thanks. My thinking here is to have the iteration over all modes, and
then filter it within the tests, with something like this at the top of
a test:
if (!INTEGRAL_MODE_P (mode))
return;
I guess that or something related can work. I'm not offhand sure if
BImode is considered integral or not :-)
I think you also have to worry about using a mode that is so side that
the optimizers punt. So for example you might want to verify that a+0
== a in OImode, but there's a nonzero chance that the optimizers might
punt OImode optimizations -- and it probably depends on the largest
target mode that can be supported by a pair of HOST_WIDE_INTs.
That said, and this is probably my relative unfamiliarity with RTL
speaking, but I'm not sure exactly how the modes should be filtered.
It's not necessarily clear to me either. I'm pointing on the most
obvious problem areas. I won't be at all surprised if we have to
iterate on this a bit after installation.
For example, my naive "run in all modes" approach ran into the issue
that although (A + 0) -> A works, (0 + A) -> A currently doesn't work
for complex modes (where "0" is CONST0_RTX(mode)). Is that a bug? If
so, since the run-in-all-modes approach uncovered it, was the testing
useful?
It depends. 0 + A isn't canonical, so I doubt the various folders have
been written to handle it consistently. There's going to be all kinds
of stuff like that.
One might ask if the folders ought to canonicalize their inputs.
Perhaps they should for the sake of consistency -- but the cost is the
testing for something that isn't supposed to ever happen internally.
OTOH other things may be a preferred form, but not necessarily a
canonical form. So for example there's multiple ways to represent a
zero extension. There was a time when shift-add might be represented as
a shift-add in one context, but mult-add in another (ugh).
So again, I don't think there's necessarily a clear answer here and the
answer may change over time (as was the case with cleaning up the
shift-add vs mult-add disaster).
If that's the case, would it make sense to have some kind of
NORMAL_MODE_P (mode) filter, say, or conversely SPECIAL_MODE_P (mode),
and do an early-reject in the loop over all modes? (to reject CCmode,
VOIDmode, BImode, I think; any others?).
I'm not necessarily sure it's that simple, but we could start with that
for basic folding and see what other knobs we need over time as the
tests grow.
jeff
Dave