PING: [PATCH, ARM, iWMMXt][4/5]: WMMX machine description

Richard Earnshaw rearnsha@arm.com
Thu Dec 22 10:12:00 GMT 2011


On 22/12/11 06:38, Xinyu Qi wrote:
> At 2011-12-15 01:32:13,"Richard Earnshaw" <rearnsha@arm.com> wrote:
>> On 24/11/11 01:33, Xinyu Qi wrote:
>>> Hi Ramana,
>>>
>>> I solve the conflict, please try again. The new diff is attached.
>>>
>>> Thanks,
>>> Xinyu
>>>
>>> At 2011-11-19 07:36:15,"Ramana Radhakrishnan"
>> <ramana.radhakrishnan@linaro.org> wrote:
>>>>
>>>> Hi Xinyu,
>>>>
>>>> This doesn't apply cleanly currently on trunk and the reject appears
>>>> to come from iwmmxt.md and I've not yet investigated why.
>>>>
>>>> Can you have a look ?
>>>>
>>
>> This patch is NOT ok.
>>
>> You're adding features that were new in iWMMXt2 (ie not in the original
>> implementation) but you've provided no means by which the compiler can
>> detect which operations are only available on the new cores.
> 
> Hi Richard,
> 
> All of the WMMX chips support WMMX2 instructions.

This may be true for Marvell's current range of processors, but I find
it hard to reconcile with the assembler support in GAS, which clearly
distinguishes between iWMMXT and iWMMXT2 instruction sets.  Are you
telling me that no cores were ever manufactured (even by Intel) that
only supported iWMMXT?

I'm concerned that this patch will break support for existing users who
have older chips (for GCC we have to go through a deprecation cycle if
we want to drop support for something we now believe is no-longer worth
maintaining).

> What I do is to complement the WMMX2 intrinsic support in GCC.

I understand that, and I'm not saying the patch can never go in; just
that it needs to separate out the support for the different architecture
variants.

> I don't think it is necessary for users to consider whether one WMMX insn is a WMMX2 insn or not.

Users don't (unless they want their code to run on legacy processors
that only support the original instruction set), but the compiler surely
must know what it is targeting.  Remember that the instruction patterns
are not entirely black boxes, the compiler can do optimizations on
intrinsics (it's one of the reasons why they are better than inline
assembly).  Unless the compiler knows exactly what instructions are
legal, it could end up optimizing something that started as a WMMX insn
into something that's a WMMX2 insn (for example, propagating a constant
into a vector shift expression).

R.



More information about the Gcc-patches mailing list