On 22/12/11 06:38, Xinyu Qi wrote: > At 2011-12-15 01:32:13,"Richard Earnshaw" <rearn...@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.radhakrish...@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.
