> I'm not sure how that would work, but it most likely wouldn't fit with the design of llvm. If this is important, I'd rather fix the representational issue. > >Just #ifdef RELAXED_FLOAT here the code like I posted #endif what do you mean by the representational issue? something in the IR? Perhaps something like the value tracking can be implemented that tracks if a float can be NaN. then only a flag is needed for the load instruction that the float from memory is assumed not to be NaN. -Jochen
On Mar 3, 2010, at 12:41 PM, Jochen Wilhelmy wrote:> >> I'm not sure how that would work, but it most likely wouldn't fit with the design of llvm. If this is important, I'd rather fix the representational issue. >> >> > Just > #ifdef RELAXED_FLOAT > here the code like I posted > #endifOk, that's what I thought, we don't want that in mainline.> what do you mean by the representational issue? something in the IR?Yes. Each fp operation should have the information tagged onto like (like nuw/nsw on integer ops). This allows inlining between functions with different settings, allows expressing things like the fortran parentheses rules etc. -Chris
Hi! I have a new idea: why not make a difference between null and 0.0 and x * null is null. null is of course only a compile time constant that can be used to remove unused parts of floating point computations, i.e. all inputs to a floating point computation that are not used can be set to null before compiling it. -Jochen