This is an archive of the discontinued LLVM Phabricator instance.

Ajust two tests implementation of TargetParserTest
AbandonedPublic

Authored by jojo on Jul 29 2016, 12:41 AM.

Details

Reviewers
rengolin
djasper
Summary

The loop from 0 ~ AEK_XSCALE(0x80000000) in these tests will over the entire int range.
Actually,the ArchExtKind from AEK_OS(0x8000000) to AEK_XSCALE(0x80000000) are unsupported extensions for now.
So do not care about these extensions in the tests of TargetParserTest.
If these extensions will be supported in the future,they would be given a reasonable value absolutely.

Diff Detail

Event Timeline

jojo updated this revision to Diff 66090.Jul 29 2016, 12:41 AM
jojo retitled this revision from to Ajust two tests implementation of TargetParserTest.
jojo updated this object.
jojo added reviewers: djasper, rengolin.
jojo added a subscriber: llvm-commits.
djasper edited edge metadata.Jul 29 2016, 12:59 AM

I am not the right reviewer here. I still believe looping over 0 to 0x8000000 is not useful and actually takes a lot of time in non-optimized builds. Is there no better way? What are you actually trying to test?

jojo added a comment.Jul 29 2016, 1:29 AM

It's possible to keep them included in the tests,just remove them from the main loop.
But I think it's meaningless,as they are unsupported in the design.
@rengolin,Could you give me some advice?

rengolin added inline comments.Jul 29 2016, 7:29 AM
unittests/Support/TargetParserTest.cpp
217

You could iterate over kHWDivKinds and kARMArchExtKinds?

218

Shouldn't this be "< AEK_LAST"?

jojo updated this revision to Diff 66287.EditedAug 1 2016, 2:20 AM
jojo edited edge metadata.

three choices:

  1. Just iterate to AEK_RAS, as shown in this diff. (smallest change)

As AEK_RAS in the enum is the last one supported in the current design,so iterate to it may seems odd but is enough.

  1. Add option AEK_LAST to enum ArchExtKind,then iterate to AEK_LAST.(biggest change, I prefer this one)

The current definition of ArchExtKind is as follow,adding an end option like FPUKind and ArchKind maybe better. Update diff
for this one.

enum ArchExtKind : unsigned {
  AEK_INVALID = 0x0,
  AEK_NONE = 0x1,
  AEK_CRC = 0x2,
  AEK_CRYPTO = 0x4,
  AEK_FP = 0x8,
  AEK_HWDIV = 0x10,
  AEK_HWDIVARM = 0x20,
  AEK_MP = 0x40,
  AEK_SIMD = 0x80,
  AEK_SEC = 0x100,
  AEK_VIRT = 0x200,
  AEK_DSP = 0x400,
  AEK_FP16 = 0x800,
  AEK_RAS = 0x1000,
  // Unsupported extensions.
  AEK_OS = 0x8000000,
  AEK_IWMMXT = 0x10000000,
  AEK_IWMMXT2 = 0x20000000,
  AEK_MAVERICK = 0x40000000,
  AEK_XSCALE = 0x80000000,
};
  1. iterate over kHWDivKinds and kARMArchExtKinds

@rengolin,What is your opinion?

rengolin edited edge metadata.Aug 15 2016, 10:39 AM
In D22956#501906, @jojo wrote:
  1. Just iterate to AEK_RAS, as shown in this diff. (smallest change)

As AEK_RAS in the enum is the last one supported in the current design,so iterate to it may seems odd but is enough.

It is odd, and error prone, if we re-order or change things.

  1. Add option AEK_LAST to enum ArchExtKind,then iterate to AEK_LAST.(biggest change, I prefer this one)

Me too. But I'm still not convinced the two additional tests (ARMArchExtName, ARMHWDivName) add anything of value.

If we make a mistake in the enum, the test will still pass, since both the enum and the test array are generated from the same source (the .def file).

We're already testing the extensions in ARMArchExtFeature, so why not just leave it at that?

cheers,
--renato

include/llvm/Support/TargetParser.h
93

AEK_LAST seems like a bad name for this... Maybe AEK_LAST_SUPPORTED?

Also, best if put in order, ie. after AEK_RAS.

lib/Support/TargetParser.cpp
205

This encodes the wrong information. This is telling you that *no* unsupported arch has HDIV, when this might not be true.

Why do you need to change this at all?

jojo abandoned this revision.Aug 28 2016, 7:38 PM
  1. Add option AEK_LAST to enum ArchExtKind,then iterate to AEK_LAST.(biggest change, I prefer this one)

Me too. But I'm still not convinced the two additional tests (ARMArchExtName, ARMHWDivName) add anything of value.

If we make a mistake in the enum, the test will still pass, since both the enum and the test array are generated from the same source (the .def file).

We're already testing the extensions in ARMArchExtFeature, so why not just leave it at that?

Indeed, agree.
For now it's ok leave it at that. Add additional test cases when there is really a need later on.
In a more reasonable way of course.

Thanks renato and djasper!