marking ppc440 tests as unsupported
Joel Sherrill
joel.sherrill@oarcorp.com
Mon Jan 12 17:36:00 GMT 2009
Joseph S. Myers wrote:
> On Mon, 12 Jan 2009, Joel Sherrill wrote:
>
>
>> The unfortunate thing is that I think these
>> tests are really ensuring that MASK_DLMZB is
>> used as expected. If this is right, then
>> shouldn't there be a cpp predefine similar
>> to __NO_LWSYNC__ for dlmzb? And the tests use
>> that rather than testing for a specific CPU model?
>>
>
> Exactly one of the tests (for each processor) is testing for dlmzb; the
> others are testing for half-word multiply instructions. The tests are
> that the compiler, generating code for those processors, with the options
> people are expected to use for those processors, generates the
> instructions. The tests are likely very sensitive to cost tuning.
>
>
Then should the half-word multiply capability also have a
predefine to indicate it is available?
My understanding so far is that when you need to figure
out if your test target platform supports a particular
feature so it can be reported as unsupported, you
have options like this:
if a scan-assembler test
- use a cpp predefine and effective target test
if a run time test
- if possible, use dynamic probe for feature to be tested
- else use cpp predefined and report unsupported
Since these are scan-assembler, I only know one option
and am looking for the right solution. Do we need to
define cpp predefines to indicate that dmlzb and
half-world multiply are enabled?
This way the knowledge would be available independent
of the CPU model. That is similar to LWSYNC.
>> And then should there be tests for the other
>> CPU models which have this feature to ensure
>> the -mcpu=[405fp|440fp|464|464fp] also do the
>> right thing? I don't see why 2 of the 6 CPU
>> models have this test.
>>
>
> It happens that all those processors use ppc405_cost or ppc440_cost, so
> the most obvious variation is already covered.
>
>
OK. I'm just a bit anal retentive when it comes to testing and
don't mind adding cases for coverage. :)
--joel
More information about the Gcc
mailing list