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.
Details
Diff Detail
Event Timeline
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?
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?
three choices:
- 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.
- 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, };
- iterate over kHWDivKinds and kARMArchExtKinds
@rengolin,What is your opinion?
It is odd, and error prone, if we re-order or change things.
- 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? |
- 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!
AEK_LAST seems like a bad name for this... Maybe AEK_LAST_SUPPORTED?
Also, best if put in order, ie. after AEK_RAS.