On 23.10.2019 11:37, George Dunlap wrote: > On 10/23/19 8:27 AM, Jan Beulich wrote: >> On 21.10.2019 13:10, George Dunlap wrote: >>> Let's do a cost-benefits analysis of always_inline vs clang_inline. >>> >>> For each future gcc version, either it will choose to inline this >>> function with the `inline` key word or not. >>> >>> 1. Use always_inline >>> 1a. gcc would have done inline anyway. No cost. >>> 1b. gcc would not have inlined it. always_inline takes effect and >>> there's no cost. >>> 2. Use clang_inline >>> 2a. gcc would have done inline anyway. No cost. >>> 2b. gcc doesn't inline it. We have random bugs, a discussion, then a >>> patch to s/clang_inline/always_inline/g;. >>> >>> IOW, I only see a cost here to 2, and no benefit. >> >> The benefit of 2 would be the easier way of identifying what was >> changed just for clang's sake, perhaps with the simple goal of >> reverting the whole lot without having to fish out all the individual >> commits that may accumulate over time. > > But they weren't done for clang's sake; they were done for symbol clash > sake. If some future version of gcc happened to not inline these, then > we'd get the same problem. > > So if you want to take this approach, I'd say make the names something > like, `inline_symbol_clash`. That tells future people exactly what > needs to be done to switch them back to "bare" inline; and if we never > get around to fixing the symbol clash issue, then it will prevent gcc > from "developing" this issue as well.
Oh, yes, good point. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
