----- Original Message ----- > > On Thu, Sep 12, 2013 at 2:03 PM, Hal Finkel < [email protected] > > wrote: > > > > > Hello, > > Please review the attached patch which restores the libm sqrt* -> > @llvm.sqrt* mapping, but only in fast-math mode (specifically, when > the UnsafeFPMath or NoNaNsFPMath CodeGen options are enabled). The > @llvm.sqrt* intrinsics have slightly different semantics from the > libm call, specifically, they are undefined when given a non-zero > negative number (the libm calls will always return NaN for any > negative number). > > This mapping was removed in r100613, and replaced with a TODO, but at > that time the fast-math flags were not yet implemented. Now that we > have these, restoring this mapping is important because it will > enable autovectorization of sqrt calls in loops (at least in > fast-math mode). > > > > > This is dangerous, if LangRef is actually correct. People don't > associate -ffast-math with "my program will crash at random". :) Of > course, LangRef is probably overstating the issue.
I agree, and the LangRef does indeed say "undefined behavior", but I assume that should really mean, "returns an undefined value." Do you agree? > > > That said, there's actually a general issue here: if we map the LLVM > intrinsics to libc functions, and the libc functions set errno, we > could break code that depends on errno for non-math calls (e.g. > fopen().) Perhaps, but I'm not changing that here. For one thing, if the mapping does, in effect, sqrt -> llvm.sqrt -> sqrt, and only when -fmath-errno=0. Are you worried about cases where the libm functions actually do set errno (even though we have -fmath-errno=0)? -Hal > > -Eli -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
