This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Rework extract-lowbits test
AbandonedPublic

Authored by jvesely on Jul 21 2018, 9:35 PM.

Details

Reviewers
arsenm
Summary

This will make it easier to add r600

Diff Detail

Repository
rL LLVM

Event Timeline

jvesely created this revision.Jul 21 2018, 9:35 PM

I'd rather stop trying to share tests with r600 at all. I would like to split out most of the shared tests as-i

I'd rather stop trying to share tests with r600 at all. I would like to split out most of the shared tests as-i

Any reason for that? Both bfe instructions use the same patterns so it'd be just a copy paste.

I'd rather stop trying to share tests with r600 at all. I would like to split out most of the shared tests as-i

Any reason for that? Both bfe instructions use the same patterns so it'd be just a copy paste.

A lot of tests have too many run lines as is, and adding more for r600 increases the mess. In this case you are actually changing the tested content. The original used VGPR inputs for everything, and this changes everything to be SGPR inputs. Both would be useful as separate tests, but we don't try particular hard to match scalar BFEs currently. Also, I want to stop artificially sharing some of the intrinsics.

jvesely abandoned this revision.Jul 23 2018, 8:11 PM

I'd rather stop trying to share tests with r600 at all. I would like to split out most of the shared tests as-i

Any reason for that? Both bfe instructions use the same patterns so it'd be just a copy paste.

A lot of tests have too many run lines as is, and adding more for r600 increases the mess. In this case you are actually changing the tested content. The original used VGPR inputs for everything, and this changes everything to be SGPR inputs. Both would be useful as separate tests, but we don't try particular hard to match scalar BFEs currently. Also, I want to stop artificially sharing some of the intrinsics.

Fair enough D49641 has been updated to include a copy of the file with EG/CM checks.
This sounds like chasing fools gold. Most RUN lines are added for new generations of gpu (gfx9, ...) and more for HSA, two lines for cayman and cypress barely make a difference.
The bit extract patterns should be recognized irrespective of whether it can be scalarized or not.

I'd rather stop trying to share tests with r600 at all. I would like to split out most of the shared tests as-i

Any reason for that? Both bfe instructions use the same patterns so it'd be just a copy paste.

A lot of tests have too many run lines as is, and adding more for r600 increases the mess. In this case you are actually changing the tested content. The original used VGPR inputs for everything, and this changes everything to be SGPR inputs. Both would be useful as separate tests, but we don't try particular hard to match scalar BFEs currently. Also, I want to stop artificially sharing some of the intrinsics.

Fair enough D49641 has been updated to include a copy of the file with EG/CM checks.
This sounds like chasing fools gold. Most RUN lines are added for new generations of gpu (gfx9, ...) and more for HSA, two lines for cayman and cypress barely make a difference.
The bit extract patterns should be recognized irrespective of whether it can be scalarized or not.

Part of the problem is I often try to add tests to the relevant files, and then I hit some crash or other issue in r

I'd rather stop trying to share tests with r600 at all. I would like to split out most of the shared tests as-i

Any reason for that? Both bfe instructions use the same patterns so it'd be just a copy paste.

A lot of tests have too many run lines as is, and adding more for r600 increases the mess. In this case you are actually changing the tested content. The original used VGPR inputs for everything, and this changes everything to be SGPR inputs. Both would be useful as separate tests, but we don't try particular hard to match scalar BFEs currently. Also, I want to stop artificially sharing some of the intrinsics.

Fair enough D49641 has been updated to include a copy of the file with EG/CM checks.
This sounds like chasing fools gold. Most RUN lines are added for new generations of gpu (gfx9, ...) and more for HSA, two lines for cayman and cypress barely make a difference.
The bit extract patterns should be recognized irrespective of whether it can be scalarized or not.

Another reason would be I sometimes try to add new tests to files where they logically go, and then hit some problem in r600. For example failing to handle function return values, so then I have to split the tests in more arbitrary ways