[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200419141229.GX25745@shell.armlinux.org.uk>
Date: Sun, 19 Apr 2020 15:12:29 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Stefan Agner <stefan@...er.ch>
Cc: clang-built-linux@...glegroups.com, arnd@...db.de,
ard.biesheuvel@...aro.org, ndesaulniers@...gle.com,
linux-kernel@...r.kernel.org, jiancai@...gle.com,
yamada.masahiro@...ionext.com, manojgupta@...gle.com,
robin.murphy@....com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 0/3] ARM: make use of UAL VFP mnemonics when possible
On Sun, Apr 19, 2020 at 02:35:48PM +0200, Stefan Agner wrote:
> To build the kernel with Clang's integrated assembler the VFP code needs
> to make use of the unified assembler language (UAL) VFP mnemonics.
>
> At first I tried to get rid of the co-processor instructions to access
> the floating point unit along with the macros completely. However, due
> to missing FPINST/FPINST2 argument support in older binutils versions we
> have to keep them around. Once we drop support for binutils 2.24 and
> older, the move to UAL VFP mnemonics will be straight forward with this
> changes applied.
>
> Tested using Clang with integrated assembler as well as external
> (binutils assembler), various gcc/binutils version down to 4.7/2.23.
> Disassembled and compared the object files in arch/arm/vfp/ to make
> sure this changes leads to the same code. Besides different inlining
> behavior I was not able to spot a difference.
>
> In v2 the check for FPINST argument support is now made in Kconfig.
Given what I said in the other thread, Clang really _should_ allow
the MCR/MRC et.al. instructions to access the VFP registers. There
is no reason to specifically block them.
As we have seen with FPA, having that ability when iWMMXT comes along
is very useful. In any case:
1. The ARM ARM (DDI0406) states that "These instructions are MRC and MCR
instructions for coprocessors 10 and 11." in section A7.8.
2. The ARM ARM (DDI0406) describes the MRC and MCR instructions as
being able to access _any_ co-processor.
So, Clang deciding that it's going to block access to coprocessor 10
and 11 because some version of the architecture _also_ defines these
as VFP instructions is really not on, and Clang needs to be fixed
irrespective of these patches - and I want to know that *is* going to
get fixed before I take these patches into the kernel.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
Powered by blists - more mailing lists