On Mon, 30 Mar 2020 08:51:05 +0200, George Spelvin wrote: > > On Mon, Mar 30, 2020 at 08:27:01AM +0200, Takashi Iwai wrote: > > On Sun, 29 Mar 2020 20:16:47 +0200, James Bottomley wrote: > >> We all assume that msecs_to_jiffies is properly optimized so there > >> should be no need to open code it like you're proposing. > > > > Yes, it'd be best if the compiler can handle it properly. > > I've tried, and can't figure out how to get the compiler to detect this > special case and not invoke the general code. In particular, for a > variable x, __builtin_constant_p(x * 1000 % 1000) is false. Even if x is > signed and ANSI lets the compiler assume that overflow doesn't happen. > > If you can do it, I'm most curious how! Actually in the very early version of msecs_to_jiffies() was all inlined, so the compiler could optimize such a case, I guess. Now it was factored out to an external function in commit ca42aaf0c861, so it became difficult. > > But also I meant to keep using the macro for consistency reason. > > IIRC, we wanted to eliminate the explicit use of HZ in the past, and > > it's how many lines have been converted with *_to_jiffies() calls. > > I don't know whether the eliminate of HZ is still wished, but > > reverting to the open code is a step backward for that. > > Well, you could always add a secs_to_jiffies(x) wrapper. But given > that it expands to basically x * HZ, some people might wonder why > you're bothering. Well, comparing with the expanded result doesn't make always sense. With such a logic, you can argue why BIT(x) macro is needed, too. After all, it's a matter of semantics. > I assumed that open-coding x * HZ was the preferred style, so that's > what I did. That's my question, too -- whether the open code is preferred for this particular purpose. thanks, Takashi
