search for: simplifyfortifiedlibcalls

...libcalls flag. It's an internal > implementation detail of the compiler, one that is better left in the past :) Do you think we still need some way to disable just the library call simplification now that it is a part of the instruction combiner? >> 1. What should be done about the `SimplifyFortifiedLibCalls` use in >> `CodeGenPrepare`? > > I think it stays where it is. CGP runs right before the code generator > kicks in. The idea here is that we want to leave the fortified libcalls > in the IR as long as possible on the off chance that instcombine or something > else can expo...

...currently pass the regression > test suite as of r161099. Looks pretty decent to me. You can also land the new LibCallSimplifier infrastructure first before you switch anything over to use it, if that helps. > Open Questions > ============== > > 1. What should be done about the `SimplifyFortifiedLibCalls` use in > `CodeGenPrepare`? I think it stays where it is. CGP runs right before the code generator kicks in. The idea here is that we want to leave the fortified libcalls in the IR as long as possible on the off chance that instcombine or something else can expose range information about un...

...points on style, implementation bugs, and other typical code review points. It is merely provided to show the general direction of the implementation. That being said, it does currently pass the regression test suite as of r161099. Open Questions ============== 1. What should be done about the `SimplifyFortifiedLibCalls` use in `CodeGenPrepare`? References ========== .. [1] PR11895 - SimplifyLibCalls should be merged into instcombine (http://llvm.org/bugs/show_bug.cgi?id=11895) -------------- next part -------------- A non-text attachment was scrubbed... Name: call-folding-merge-proposal.patch Type: applic...

...that it is a part of the instruction combiner? It should just be part of instcombine, but be gated by what TargetLibraryInfo says. If you want to turn off these libcall optimizations, it should be by marking the libcalls as off-limits in TLI. > >>> 1. What should be done about the `SimplifyFortifiedLibCalls` use in >>> `CodeGenPrepare`? >> >> I think it stays where it is. CGP runs right before the code generator >> kicks in. The idea here is that we want to leave the fortified libcalls >> in the IR as long as possible on the off chance that instcombine or something...

...*)in libLLVMTransformUtils.a(BuildLibCalls.cpp.o) llvm::EmitMemChr(llvm::Value*, llvm::Value*, llvm::Value*, llvm::IRBuilder<true, llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true> >&, llvm::TargetData const*)in libLLVMTransformUtils.a(BuildLibCalls.cpp.o) llvm::SimplifyFortifiedLibCalls::fold(llvm::CallInst*, llvm::TargetData const*)in libLLVMTransformUtils.a(BuildLibCalls.cpp.o) llvm::SimplifyFortifiedLibCalls::fold(llvm::CallInst*, llvm::TargetData const*)in libLLVMTransformUtils.a(BuildLibCalls.cpp.o) llvm::SimplifyFortifiedLibCalls::fold(llvm::CallInst*, llvm::Targ...