(Re-add cfe-commits; otherwise same) > -----Original Message----- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Duncan P. N. Exon Smith via cfe-commits > Sent: Monday, January 09, 2017 4:10 PM > To: reviews+d28404+public+53e0f4655ef79...@reviews.llvm.org > Cc: nhaeh...@gmail.com; wei.di...@amd.com; jholewin...@nvidia.com; Richard > Smith; cfe-commits; Peter Collingbourne > Subject: Re: [PATCH] D28404: IRGen: Add optnone attribute on function > during O0 > > This seems like a massive rehash of a discussion Peter Collingbourne and I > had about passing -O0 to the linker for -flto=full. I had previously > thought of LTO as "link time optimization", but in practice it's useful > for (and required for correctness of some) non-optimization IR passes. > > In other words, the basic question seems to be: "Should LTO support non- > optimization use cases?" I tend (now) to think it should -- having > "optimization" in its name is an historical artifact -- because adding > another way to run IR passes at link-time seems redundant. Whereas, Paul, > it seems like you disagree?
I am persuaded that there are non-optimization-based uses for clumps of bitcode modules linked together. (We could redefine the TLA if we like; LTO = Link Time Operation?) I am equally convinced that we have no good story for propagating a variety of optimization- and codegen-related options to the top-level LTO processor. This is most especially true when different CUs might reasonably have different options. -O0 is the example at hand, but this problem seems to keep coming up and we keep hacking in ways to get the thing we think we need in the moment. > > (Also, this discussion seems higher level than just the patch at hand... > maybe llvm-dev would be more appropriate?) I'd be fine with that. --paulr > > > On 2017-Jan-09, at 16:03, Paul Robinson via Phabricator > <revi...@reviews.llvm.org> wrote: > > > > 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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits