On Fri, Apr 6, 2012 at 11:27 PM, Chad Rosier <[email protected]> wrote: > > 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.
If +neonfp isn't checking for -ffast-math to be set, then that would seem to be incorrect. Rounding-mode sensitive code should not have -ffast-math set and that should ensure that that one internal group gets the results they need. ... >> 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). That's a very helpful data point. We already have too many flags to control float ABI, etc., so I wanted to avoid adding any more if we can. deep _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
