This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.
modes I think should be forbidden for these tests.  THere may be
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))
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
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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]