ARM: VFPv3-D16 vs. VFPv3-D32
Hello, it seems that it is not possible to deduce from GCC built-in defines whether we compile for the VFPv3-D16 or VFPv3-D32 floating point unit. touch empty.c arm-eabi-gcc -march=armv7-r -mfpu=vfpv3-d16 -mfloat-abi=hard -E -P -v -dD empty.c > vfpv3-d16.txt arm-eabi-gcc -march=armv7-r -mfpu=vfpv3 -mfloat-abi=hard -E -P -v -dD empty.c > vfpv3-d32.txt diff vfpv3-d16.txt vfpv3-d32.txt Is it possible to add a built-in define for this? Or as an alternative is it possible to use a GCC configuration target specific multi-lib define that indicates it? I want to use such a compiler provided define to determine how the context switch support in an operating system should look like. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: ARM: VFPv3-D16 vs. VFPv3-D32
Which Cortex-R you are targeting that supports both D16 and D32? Thanks, Joey On Thu, Oct 17, 2013 at 3:13 PM, Sebastian Huber wrote: > Hello, > > it seems that it is not possible to deduce from GCC built-in defines whether > we compile for the VFPv3-D16 or VFPv3-D32 floating point unit. > > touch empty.c > > arm-eabi-gcc -march=armv7-r -mfpu=vfpv3-d16 -mfloat-abi=hard -E -P -v -dD > empty.c > vfpv3-d16.txt > > arm-eabi-gcc -march=armv7-r -mfpu=vfpv3 -mfloat-abi=hard -E -P -v -dD > empty.c > vfpv3-d32.txt > > diff vfpv3-d16.txt vfpv3-d32.txt > > Is it possible to add a built-in define for this? Or as an alternative is > it possible to use a GCC configuration target specific multi-lib define that > indicates it? > > I want to use such a compiler provided define to determine how the context > switch support in an operating system should look like. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: ARM: VFPv3-D16 vs. VFPv3-D32
On 2013-10-17 09:28, Joey Ye wrote: Which Cortex-R you are targeting that supports both D16 and D32? I have a Cortex-R variant which supports D16 only and now I want to add a multi-lib to our GCC target configuration and use a compiler built-in to adjust the context switch code for this multi-lib. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: ARM: VFPv3-D16 vs. VFPv3-D32
There is no macro to indicate VFP variances. Probably you can check CPU variance instead. As I know Cortex-R only support D16. Joey On Thu, Oct 17, 2013 at 3:47 PM, Sebastian Huber wrote: > On 2013-10-17 09:28, Joey Ye wrote: >> >> Which Cortex-R you are targeting that supports both D16 and D32? > > > I have a Cortex-R variant which supports D16 only and now I want to add a > multi-lib to our GCC target configuration and use a compiler built-in to > adjust the context switch code for this multi-lib. > > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Compilation flags in libgfortran
On Wed, Oct 16, 2013 at 12:22 PM, Kyrill Tkachov wrote: > On 16/10/13 10:37, pins...@gmail.com wrote: >>> >>> On Oct 15, 2013, at 6:58 AM, Igor Zamyatin wrote: >>> Hi All! >>> >>> Is there any particular reason that matmul* modules from libgfortran >>> are compiled with -O2 -ftree-vectorize? >>> >>> I see some regressions on Atom processor after r202980 >>> (http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00846.html) >>> >>> Why not just use O3 for those modules? >> >> -O3 and -O2 -ftree-vectorize won't give much performance difference. What >> you are seeing is the cost model needs improvement; at least for atom. > > Hi all, > I think http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01908.html introduced > the new "cheap" vectoriser cost model that favors compilation time over > runtime performance and is set as default for -O2. -O3 uses the "dynamic" > model which potentially gives better runtime performance in exchange for > longer compile times (if I understand the new rules correctly). > Therefore, I'd expect -O3 to give a better vector performance than -O2... But this suggests to compile with -O2 -ftree-vectorize -fvect-cost-model=dynamic, not building with -O3. Richard. > Kyrill > >
Re: ARM: VFPv3-D16 vs. VFPv3-D32
On 17/10/13 08:56, Joey Ye wrote: > There is no macro to indicate VFP variances. Probably you can check > CPU variance instead. As I know Cortex-R only support D16. > Checking __ARM_ARCH_PROFILE == 'R' would tell you that it's R profile and therefore only 16 regs. R. > Joey > > On Thu, Oct 17, 2013 at 3:47 PM, Sebastian Huber > wrote: >> On 2013-10-17 09:28, Joey Ye wrote: >>> >>> Which Cortex-R you are targeting that supports both D16 and D32? >> >> >> I have a Cortex-R variant which supports D16 only and now I want to add a >> multi-lib to our GCC target configuration and use a compiler built-in to >> adjust the context switch code for this multi-lib. >> >> >> -- >> Sebastian Huber, embedded brains GmbH >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >> Phone : +49 89 189 47 41-16 >> Fax : +49 89 189 47 41-09 >> E-Mail : sebastian.hu...@embedded-brains.de >> PGP : Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > >
Re: ARM: VFPv3-D16 vs. VFPv3-D32
On 2013-10-17 14:24, Richard Earnshaw wrote: On 17/10/13 08:56, Joey Ye wrote: >There is no macro to indicate VFP variances. Probably you can check >CPU variance instead. As I know Cortex-R only support D16. > Checking __ARM_ARCH_PROFILE == 'R' would tell you that it's R profile and therefore only 16 regs. Thanks for this information. I was not aware that no existing Cortex-R variant has a D32 VFP unit. Is the converse true for Cortex-A variants or are there Cortex-A cores with VFP-D16 and VFP-D32 units? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: ARM: VFPv3-D16 vs. VFPv3-D32
On 17/10/13 13:46, Sebastian Huber wrote: > On 2013-10-17 14:24, Richard Earnshaw wrote: >> On 17/10/13 08:56, Joey Ye wrote: There is no macro to indicate VFP variances. Probably you can check CPU variance instead. As I know Cortex-R only support D16. >> Checking __ARM_ARCH_PROFILE == 'R' would tell you that it's R profile >> and therefore only 16 regs. > > Thanks for this information. I was not aware that no existing Cortex-R > variant > has a D32 VFP unit. > > Is the converse true for Cortex-A variants or are there Cortex-A cores with > VFP-D16 and VFP-D32 units? > No, the converse is not true. In general (though I don't think there's a guarantee that this will be the case) if you don't have Neon you won't have D32. However, if you have Neon you must have D32. Not all Cortex-A cores have Neon; though many do these days. R.
