[RFC PATCH v1 13/50] Avoid some useless msecs/jiffies conversions

[Takashi Iwai]

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