This is an archive of the discontinued LLVM Phabricator instance.

[RFC] Refactor TargetParserTests
ClosedPublic

Authored by jojo on Nov 6 2016, 10:25 PM.

Details

Summary

The target parser tests are a bit redundant. Refactor the tests hard-coding the expectations in the test themselves.
For example, given a CPU, what's the expcted arch, fpu, flags, etc.

Refact part of tests first, if this could be accepted ,then change all the other tests in this patttern later.

Diff Detail

Event Timeline

jojo updated this revision to Diff 77007.Nov 6 2016, 10:25 PM
jojo retitled this revision from to [RFC] Refactor TargetParserTests.
jojo updated this object.
jojo added a subscriber: llvm-commits.
rengolin edited edge metadata.Nov 6 2016, 10:36 PM

Hi Jojo,

Thanks for the patch. Other checks we could do here:

  • for each arch, what's the default CPU.
  • given some arch/CPU, make sure some extensions are *not* accepted. For these, one each or even less would be fine.
jojo updated this revision to Diff 77011.Nov 6 2016, 10:37 PM
jojo edited edge metadata.
jojo updated this revision to Diff 77306.Nov 8 2016, 7:55 PM

Done the refactoring.

Thanks Jojo,

It's looking much better. A new round of comments.

cheers,
--renato

unittests/Support/TargetParserTest.cpp
19–20

"cpu" -> "CPUName"

29

nit: curly brackets to help identifying the if with the else.

30

I think this could also work if any one flag was set by itself, so:

if (ExtKind <= 1 || isPowerOfTwo(ExtKind)) {

could be a more optimal solution, to avoid the long path.

32

I have the impression that the string representation is redundant.

Instead of generating the string representation of the default extensions, then comparing to the given string, I think you should just pass the values as unsigned ex. (CRC | DSP), then compare with the result from getDefaultExtensions.

142

formatting: move all lines to the same style.

Pass clang-format on the patch, and then make sure that the alignment is the same, even if not needed.

Example, if one call needs the ARMBuildAttrs to be on a new line (>80 cols), then all of them should.

This makes it easier to "see" what's going on.

206

I like these tests, but would be good to make them check for a feature that is close enough, but not implemented.

For example, vfp on pre-v5, vfpv3 on pre-v7, vfpv4 on cortex-a8, etc.

Also, the v7M cores are redundant, you only need to test one v6M (M0) and one v7M (M3).

574–678

The same comments for the ARM implementation apply here.

647

We now have v8M and v8R.

669

I think v8.2A has FP by default. If this test returns FALSE, then there's something wrong with the code. :)

jojo updated this revision to Diff 79365.Nov 27 2016, 7:10 PM

Inline comments.

unittests/Support/TargetParserTest.cpp
32

Good idea! This make the code more simple.Thanks.

206

Indeed. Make sense.
I don't know enough on ARM architecture. So I have to make them as close as possible according to information collected from the net.
There may still be a lot of inappropriate,please let me know.

647

AFAIK, both of them are 32bit.
And v8R has been supported in ARMTargetParser.
There is still no support in ARM backend for v8M,
Should we add it to targetparser after it is actually
supported in the backend?

669

Yes,indeed. There is a incorrect index problem in this test.
No errors printed make me missed the wrong flags here.

Sorry for the delay, I'm wondering if the &= is the reason why you're getting the wrong expectation on the tests...

unittests/Support/TargetParserTest.cpp
40

Shouldn't this be ret |=?

582

Same here.

647

Yes, because this tests the parser, not the target support.

jojo added a comment.Dec 2 2016, 1:17 AM

I'm wondering if the &= is the reason why you're getting the wrong expectation on the tests...

The reason why a wrong flag for v8.2 was not exposed is I misused enums of ARM for ArchKind
there in the last diff.

unittests/Support/TargetParserTest.cpp
40

It will return "true" here, only when all the items are the values that we expect.
So it should return a value after "&=".

582

Same as above.

rengolin accepted this revision.Dec 2 2016, 2:07 AM
rengolin edited edge metadata.

Ok, I think this looks much better than what we had, and it's a more meaningful testing strategy.

The repetitiveness will help other people adding tests whenever they add a new core/extension, too.

With the small change I proposed in the inline comment, LGTM.

Thanks!
--renato

unittests/Support/TargetParserTest.cpp
40

Right, my mind was in the "true if it fails" which is pervasive throughout the back-end, mainly because you initialised it as "false". :)

Since the first ret will override, I think you can declare ret at the same time:

bool ret = ARM::getArchName(ArchKind).equals(ExpectedArch);
...

Maybe even call it pass, so it's clearer what it means.

This revision is now accepted and ready to land.Dec 2 2016, 2:07 AM
jojo closed this revision.Dec 5 2016, 7:38 PM

Committed r288758