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
