probinson added a comment. In https://reviews.llvm.org/D28404#641078, @chandlerc wrote:
> For me, the arguments you're raising against -O0 and -flto don't hold up on > closer inspection: > > - O0 != optnone: correct. But this is only visible in LTO. And in LTO, Os != > optsize, and Oz != minsize. But we use optsize and minsize to communicate > between the compilation and the LTO step to the best of our ability the > intent of the programmer. It appears we can use optnone exactly the same way > here. If the design decision is that relevant optimization controls are propagated into bitcode as function attributes, I grumble but concede it will do something similar to what was requested. It does bother me that we keep finding things that LTO needs to know but which it does not know because it runs in a separate phase of the workflow. I hope it is not a serious problem to ask "is there a more sensible way to fix this?" Maybe I'm not so good at expressing that so it comes out as a question rather than an objection, but that's basically what it is. This design decision leaves -O1/-Og needing yet another attribute, when we get around to that, but I suppose Og would not have the interaction-with-other-attributes problems that optnone has. > - optnone isn't *really* no optimizations: clearly this is true, but then > neither is -O0. We run the always inliner, a couple of other passes, and we > run several parts of the code generators optimizer. I understand why optnone > deficiencies (ie, too many optimizations) might be frustrating, but having > *more users* seems likely to make this *better*. We have picked all the low-hanging fruit there, and probably some medium-hanging fruit. Mehdi did have the misunderstanding that optnone == -O0 and that I think was worth correcting. > - There is no use case for -O0 + -flto: The email thread has an exchange between Duncan and me, where I accept the use case. > But all of this seems like an attempt to argue "you are wrong to have your > use case". I personally find that an unproductive line of discussion. Not saying it was *wrong* just the description did not convey adequate justification. Listing a few project types does not constitute a use case. We did get to one, eventually, and it even involved differences in optimization levels. > For example, you might ask: could we find some other way to solve the problem > you are trying to solve here? There is another way to make use of the attribute, which I think will be more robust: Have Sema pretend the pragma is in effect at all times, at -O0. Then all the existing conflict detection/resolution logic Just Works, and there's no need to spend 4 lines of code hoping to replicate the correct conditions in CodeGenModule. Because Sema does not have a handle on CodeGenOptions and therefore does not a-priori know the optimization level, probably the right thing to do is move the flag to LangOpts and set it under the correct conditions in CompilerInvocation. It wouldn't be the first codegen-like option in LangOpts. https://reviews.llvm.org/D28404 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
