> These flags only affect the code generator. If you want to add this optimization to your copy of llvm, you can do so by adding it to the instcombine pass. We'd need IR enhancements to do this sort of thing for real in the mid-level optimizer, some thoughts are here: > http://nondot.org/sabre/LLVMNotes/FloatingPointChanges.txt >Thanks, now it works. I inserted if (Op1F->isNullValue()) return ReplaceInstUsesWith(I, Op1C); // X * 0 == 0 into llvm::InstCombiner::visitFMul Why not at first create a compile time option for this so that the code is already available for special purposes? -Jochen
On Mar 3, 2010, at 11:07 AM, Jochen Wilhelmy wrote:> >> These flags only affect the code generator. If you want to add this optimization to your copy of llvm, you can do so by adding it to the instcombine pass. We'd need IR enhancements to do this sort of thing for real in the mid-level optimizer, some thoughts are here: >> http://nondot.org/sabre/LLVMNotes/FloatingPointChanges.txt >> > > Thanks, now it works. I inserted > > if (Op1F->isNullValue()) > return ReplaceInstUsesWith(I, Op1C); // X * 0 == 0 > > into llvm::InstCombiner::visitFMul > > Why not at first create a compile time option for this so that the > code is already available for special purposes?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. -Chris
On Wednesday 03 March 2010 13:13:50 Chris Lattner wrote:> > Why not at first create a compile time option for this so that the > > code is already available for special purposes? > > 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.I agree. The option should control the kind of IR generated as Chris outlined in the document. We need to figure out exactly what "strict" means. Is it like "restrict" in C where it only has meaning with respect to other things marked "restrict" or is it more general? Can I reassociate a strict with a relaxed? Is it possible that "strict" will mean different things for different operations? We may need something akin to a fence over which no code motion can occur. Some compilers use special operations to represent parentheses for Fortran codes. I don't think that will work very well for LLVM, however. I think the proposal is heading in the right direction. We just need to fill in the details. -Dave
> 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