2010/11/8 Zhang, Austin <[email protected]>: > Carsten, > > Sorry for top-post. Post flow still seems nice, so that should be OK. > >> Marvell Dove and Nvidia Tegra 2 is VFPv3-D16, which means our current >> ARMv7 port does not at all run on Marvell Dove or Nvidia Tegra 2 - it >> doesn't have the registers 17-32 which our code uses. This was one key >> argument against enabling NEON by default. > If VFPv3 is described as "Broadly compatible with VFPv2 but adds ...", here > v2 has only 16 64-bit FPU registers. > Then what it is describing is only ISA compatible and no possible at runtime > compatible like soft Vs softfp? > Will those No.17-32 registers were definitely used in all cases if we use > -mfpu=vfpv3? (default as D32) At least very simple code was generating assembly that used registers d16, d17 and above, according to thiago on IRC (counting registers from zero).
> >> For hardfp there could be a small discussion if we'd use vfpv3-d16 to >> include more target possibilities, > IMHO, the reason to use hard is for those performance benefit from hard flag, > then put compatibility as 2nd considering, if so, > why still use vfpv3-d16 (which is implicitly meaning for compatibility with > most part of HD). Good argument, if our target with hardfp is performance, we should set high bar and allow NEON (I think that's what you're saying, correct me if I'm wrong) >> but for softfp we might as well move ahead to mfpu=neon. > As that link you pointed out: > "While optimizing the entire system for NEON would be awesome, there is very > little benefit on standard code " Well, may be better to phrase it as: to enable NEON in the places that has use of it, glibc, Qt, codecs, etc. Before, we would be worried to enable this by standard without guards. BR Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
