mehdi_amini added a comment. In https://reviews.llvm.org/D28404#640284, @probinson wrote:
> In https://reviews.llvm.org/D28404#640178, @mehdi_amini wrote: > > > In https://reviews.llvm.org/D28404#640170, @probinson wrote: > > > > > In https://reviews.llvm.org/D28404#640090, @mehdi_amini wrote: > > > > > > > In https://reviews.llvm.org/D28404#640046, @probinson wrote: > > > > > > > > > "I don't care" doesn't seem like much of a principle. > > > > > > > > > > > > Long version is: "There is no use-case, no users, so I don't have much > > > > motivation to push it forward for the only sake of completeness". Does > > > > it sound enough of a principle like that? > > > > > > > > > No. You still need to have adequate justification for your use case, > > > which I think you do not. > > > > > > I don't follow your logic. > > IIUC, you asked about "why not supporting `O1/O2/O3`" ; how is *not > > supporting* these because their not useful / don't have use-case related to > > "supporting `O0` is useful"? > > > Upfront, it seemed peculiar to handle only one optimization level. After > more thought, the whole idea of mixing -O0 and LTO seems wrong. Sorry, > should have signaled that I had changed my mind about it. You just haven't articulated 1) why it is wrong and 2) what should we do about it. > > >>>>> Optnone does not equal -O0. It is a debugging aid for the programmer, >>>>> because debugging optimized code sucks. If you have an LTO-built >>>>> application and want to de-optimize parts of it to aid with debugging, >>>>> then you can use the pragma, as originally intended. >>>> >>>> Having to modifying the source isn't friendly. Not being able to honor -O0 >>>> during LTO is not user-friendly. >>> >>> IMO, '-O0' and '-flto' are conflicting options and therefore not deserving >>> of special support. >> >> You're advocating for *rejecting* O0 built module at link-time? We'd still >> need to detect this though. Status-quo isn't acceptable. >> Also, that's not practicable: what if I have an LTO static library for >> which I don't have the source, now if I build my own file with -O0 -flto I >> can't link anymore. > > No, I'm saying they are conflicting options on the same Clang command line. > As long as your linker can handle foo.o and bar.bc on the same command line, > not a problem. (If your linker can't handle that, fix the linker first.) You just wrote above that " mixing -O0 and LTO " is wrong, *if* I were to agree with you at some point, then I'd make it a hard error. >>> In my experience, modifying source is by far simpler than hacking a build >>> system to make a special case for compiler options for one module in an >>> application. (If you have a way to build Clang with everything done LTO >>> except one module built with -O0, on Linux with ninja, I would be very >>> curious to hear how you do that.) >> >> Static library, separated projects, etc. >> We have tons of users... > > Still waiting. Waiting for what? We have use-cases, I gave you a few (vendor static libraries are one). Again, if you think it is wrong to support O0 and LTO, then please elaborate. >>>>> I don't think `-c -O0` should get this not-entirely-O0-like behavior. >>>> >>>> What is "not-entirely"? And why do you think that? >>> >>> "Not entirely" means that running the -O0 pipeline, and running an >>> optimization pipeline but asking some subset of passes to turn themselves >>> off, does not get you the same result. And I think that because I'm the >>> one who put 'optnone' upstream in the first place. The case that >>> particularly sticks in my memory is the register allocator, but I believe >>> there are passes at every stage that do not turn themselves off for optnone. >> >> That's orthogonal: you're saying we are not handling it correctly yet, I'm >> just moving toward *fixing* all these. > > It's not orthogonal; that's exactly how 'optnone' behaves today. If you have > proposed a redesign of how to mix optnone and non-optnone functions in the > same compilation unit, in some way other than what's done today, I am not > aware of it; can you point to your proposal? I don't follow: IMO if I generate a module with optnone and pipe it to `opt -O3` I expect no function IR to be touched. If it is not the case it is a bug. https://reviews.llvm.org/D28404 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
