New Issue: Improve test coverage for all the different ways to fail to gpuize

stonea1 · September 2, 2022, 7:06pm

20617, "stonea", "Improve test coverage for all the different ways to fail to gpuize", "2022-09-02T19:05:43Z"

Improve test coverage for all the different ways to fail to gpuize

opened 07:05PM - 02 Sep 22 UTC

area: Tests / Benchmarks area: GPU Support

In this PR: https://github.com/chapel-lang/chapel/pull/20615 I addressed a… nightly test failure that showed up in our gpu-gasnet configuration that (at least appears) to not have anything to do with multilocale settings or GASNET. It would be nice if we had test coverage for all the different ways we could fail to GPUize in our "main" test suite. Some of these failure modes have to do with pattern-matching code not matching the way we expect so it's somewhat difficult to come up with examples that will fail. At least for the "fail to match expected upper bound" pattern the PR mentioned above triggers it (so we know there's at least one way the Chapel compiler is able to produce code like that). For the PR mentioned above the loop in question was coming from the following Chapel code: `[ (aa,bb) in zip(A, B) ] { ... }` But simply putting this with an `assertOnGpu()` isn't triggering the expected failure: so there must be some specific types for one of these variables or some other detail I'm missing. I think `test/gpu/native/assertOnFailToGpuize.chpl` would be a good test to beef up to include all these different failure modes (as it contains a good set of them already).

In this PR:

github.com/chapel-lang/chapel

accidentally allow gpuization on failing upper-bounds check

chapel-lang:main ← stonea:fix_missing_reject_to_gpuize

opened 06:55PM - 02 Sep 22 UTC

stonea

+1 -0

This is a bug introduced by an earlier PR: https://github.com/chapel-lang/chapel…/pull/20593, which was causing the following test to fail with a sefault: `gpu/native/multiLocale/cyclicDist`. Basically I added a better error message in a case where we fail to gpuize but I accidentally removed the `return false` statement that indicates we should fail to gpuize. The fix for this is easy but what's more concerning is this shows we only have test coverage for this particular failure mode in our gasnet/multilocale test configuration. The (expected) fail-to-gpuize occurs when we have a CForLoop who's upper bound doesn't match the expected pattern. I'll add another issue about trying to beef up test coverage for this (and related cases) but I'll do it outside this PR.

I addressed a nightly test failure that showed up in our gpu-gasnet configuration that (at least appears) to not have anything to do with multilocale settings or GASNET.

It would be nice if we had test coverage for all the different ways we could fail to GPUize in our "main" test suite.

Some of these failure modes have to do with pattern-matching code not matching the way we expect so it's somewhat difficult to come up with examples that will fail. At least for the "fail to match expected upper bound" pattern the PR mentioned above triggers it (so we know there's at least one way the Chapel compiler is able to produce code like that).

For the PR mentioned above the loop in question was coming from the following Chapel code:

[ (aa,bb) in zip(A, B) ] { ... }

But simply putting this with an assertOnGpu() isn't triggering the expected failure: so there must be some specific types for one of these variables or some other detail I'm missing.

I think test/gpu/native/assertOnFailToGpuize.chpl would be a good test to beef up to include all these different failure modes (as it contains a good set of them already).