On Apr 6, 2012, at 3:53 PM, Sandeep Patel wrote: > On Fri, Apr 6, 2012 at 10:16 PM, Chad Rosier <[email protected]> wrote: >> >> On Apr 6, 2012, at 3:13 PM, Sandeep Patel wrote: >> >>> Is this really necessary as a driver-level option? >>> >>> Can't this be inferred from other existing tuning choice (e.g. which >>> core IP is used)? >> >> No, that's why it was added. > > If we have a Cortex-A8 vs A9, we can know which approach is going to > be faster always, don't we?
In general, this is the case, but in this instance it's a correctness issue. The specific code requires the VFP floating point rounding modes to function correctly. > >>> How likely is somebody going to want to change this? >> >> One of our internal teams requires the ability to use VFP as opposed to NEON. Prior to this commit the only way to disable the use of NEON for scalar floating point was to use -mcpu=cortex-a9, but that isn't an option if you need to be sure the code runs on cortex-a8. > This is on a core with Neon that we know from other flags we're > targeting? (I can't quite see why this would be needed except as a > workaround for a performance edge case when neonfp is slower.) Again, correctness issue in this case. > I'm generally against providing tweakable driver-level params to > people that won't understand them and will constantly fiddle with > them, hoping to get better performance. Can't we keep this as a cc1 > flag only? gcc has a flag by the same name used for the x86 architecture (not that I'm championing gcc). Chad > deep _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
