probinson added a comment. In https://reviews.llvm.org/D28404#640588, @mehdi_amini wrote:
> Actually, as mentioned before, I could be fine with making `O0` incompatible > with LTO, however security features like CFI (or other sort of whole-program > analyses/instrumentations) requires LTO. Well, "requires LTO" is overstating the case, AFAICT from the link you gave me. Doesn't depend on //optimization// at all. It depends on some interprocedural analyses given some particular scope/visibility boundary, which it is convenient to define as a set of linked bitcode modules, that by some happy chance is the same set of linked bitcode modules that LTO will operate on. If it's important to support combining a bitcode version of my-application with your-bitcode-library for this CFI or whatever, and you also want to let me have my-application be unoptimized while your-bitcode-library gets optimized, NOW we have a use-case. (Maybe that's what you had in mind earlier, but for some reason I wasn't able to extract that out of any prior comments. No matter.) I'm now thinking along the lines of a `-foptimize-off` flag (bikesheds welcome) which would set the default for the pragma to 'off'. How is that different than what you wanted for `-O0`? It is defined in terms of an existing pragma, which is WAY easier to explain and WAY easier to implement. And, it still lets us say that `-c -O0 -flto` is a mistake, if that seems like a useful thing to say. Does that seem reasonable? Fit your understanding of the needs? https://reviews.llvm.org/D28404 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
