This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, i386]: Remove sse{,2} effective target check from compile-time tests


On Fri, Jul 23, 2010 at 8:18 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Fri, Jul 23, 2010 at 5:15 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Fri, Jul 23, 2010 at 7:43 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>>> On Fri, Jul 23, 2010 at 3:51 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>
>>>> I am not against this patch. I just think the xxx-runtime addition was
>>>> a bad idea. Most, if not all, SSE/AVX tests, which require
>>>> effective SSE/AVX targets, are run-time tests. There may be a few
>>>> of them are assemble/link tests. We should have added a different
>>>> effective proc just for them. The change would have been very small.
>>>> I guess it was too late to redo it now.
>>>
>>> There are two approaches, as far as x86 tests are concerned. One
>>> approach was invented for gcc.target/i386 tests and the other for all
>>> other test directories.
>>>
>>> a) gcc.target/i386:
>>>
>>> These tests are protected by sse{,2,...,n} and avx effective targets.
>>> These effective targets tests check if the whole toolchain is able to
>>> compile the test, but the real hardware/OS support will be checked by
>>> the executable itself and will terminate early on targets that can't
>>> execute all instructions. The benefit for this approach can be seen
>>> for i.e. AVX tests. Using recent enough binutils, even if the hardware
>>> can not support the execution, the test _can_ be compiled all the way
>>> to the executable, so toolchain can be tested as far as possible.
>>>
>>
>> If there is no hardware/OS support, do we still run those run-time tests
>> or just skip them?
>
> We run them.
>

2 issues if we still run those tests when there is no hardware/OS support:

1. Each test needs t do a run-time check. I don't see why we
need the new proc to check hardware/OS support.
2. Passing those tests doesn't mean implementation is correct,
encoding could be wrong or wrong instructions could be
generated.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]