On 7/31/19 5:31 PM, Richard Henderson wrote: > On 7/31/19 1:09 PM, Aleksandar Markovic wrote: >> >> >> On Wed, Jul 31, 2019 at 9:51 PM Richard Henderson >> <richard.hender...@linaro.org >> <mailto:richard.hender...@linaro.org>> wrote: >> >> On 7/31/19 10:57 AM, Jan Bobek wrote: >> > +static inline void gen_gvec_cmpeq(unsigned vece, uint32_t dofs, >> > + uint32_t aofs, uint32_t bofs, >> > + uint32_t oprsz, uint32_t maxsz) >> > +{ >> > + tcg_gen_gvec_cmp(TCG_COND_EQ, vece, dofs, aofs, bofs, oprsz, >> maxsz); >> > +} >> ... >> > +static inline void gen_gvec_cmpgt(unsigned vece, uint32_t dofs, >> > + uint32_t aofs, uint32_t bofs, >> > + uint32_t oprsz, uint32_t maxsz) >> > +{ >> > + tcg_gen_gvec_cmp(TCG_COND_GT, vece, dofs, aofs, bofs, oprsz, >> maxsz); >> > +} >> >> Drop the inlines. >> >> >> Why? The compiler will decide at the end of the day, but at least "inline" >> here >> says that the code author thinks that inlining is desirable, logical, and >> expected >> in these cases, which is in turn a valuable information for the code reader. > > In this case it is in fact a lie that will only confuse the reader, as it did > you. Functions whose address are passed as a callback, as these are, are > always forced out of line. > > But beyond that, clang diagnoses unused static inline within *.c while gcc > does > not (I'm not sure I agree with clang, but it is what it is). By leaving off > the inline, but compilers will diagnose when code rearrangement leaves a > function unused.
Dang, I completely forgot about the function-address vs. inlining rule. I thought of these as macros, really; they are only functions because I needed to pass them to the gen_gvec_ld_modrm_* helpers. I'll drop the inline, compilers ignore it anyway. -Jan
signature.asc
Description: OpenPGP digital signature
