dblaikie added a comment. In D104342#2831733 <https://reviews.llvm.org/D104342#2831733>, @nickdesaulniers wrote:
> In D104342#2831717 <https://reviews.llvm.org/D104342#2831717>, @dblaikie > wrote: > >> I don't know that there's a good answer (in more extreme cases - like >> different optimization levels or CPU features, at least at Google our answer >> has ended up being "compile the whole program with the right CPU features, >> because there's no great way to support good optimizations while respecting >> CPU features on a per-function basis"), basically - so this was more a >> "heads up, this is going to be possibly unavoidably messy/unreliable on the >> edges". >> >> Probably worth at least writing up the risk/instability in the docs for the >> warning (in clang) and attribute (in llvm). (don't mind if that's in this >> patch or a follow-up). > > Sure. Let me land this, since we (Google & ClangBuiltLinux) have some tests > and builds failing due to https://reviews.llvm.org/D103928. I will then send > a follow up for us to iterate on in regards to documenting this more. > >> (why I think there's no solution to this: any rule (highest wins, lowest >> wins, mismatch fails to compile) will create surprising/problematic effects, >> eg: you have one TU with the function in it and some value for the attribute >> - a new TU could introduce a copy of the function with a higher or lower >> value - and whichever choice of policy would then cause problems for one >> case or the other case. (either enforcing a stronger warning level on code >> that didn't ask for it, or slackening the warning level for code that >> thought it was protected by the warning)) > > I agree. I don't think even having a function attribute in C for > `-Wframe-larger-than` would resolve such policy issues either. At least then we could probably say it's an ODR violation (the two function definitions would be not the same if the user wrote the attribute differently for two definitions of the inline function in two different translation units) to have the function declared with different values for the attribute within the same program (so you could still compile two different files (that include a common header with a common function with the attribute specified there) with different values for the command line flag - because the function would get a consistent attribute value for the warning) - and then the linker could actually reject it on mismatch. But with the attribute currently coming from the command line, that's not feasible. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D104342/new/ https://reviews.llvm.org/D104342 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
