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