On Wed 13-07-16 00:50:12, Chen Gang wrote: > > > On 7/12/16 15:48, Michal Hocko wrote: > > On Tue 12-07-16 03:47:42, Chen Gang wrote: > > [...] > >> In our case, the 2 output size are same, but under x86_64, the insns are > >> different. After uses bool, it uses push/pop instead of branch, for me, > >> it should be a little better for catching. > > > > The code generated for bool version looks much worse. Look at the fast > > path. Gcc tries to reuse the retq from the fast path in the bool case > > and so it has to push rbp and rbx on the stack. > > > > That being said, gcc doesn't seem to generate a better code for bool so > > I do not think this is really worth it. > > > > The code below also merge 3 statements into 1 return statement, although > for me, it is a little more readable, it will generate a little bad code. > That is the reason why the output looks a little bad. > > In our case, for gcc 6.0, using bool instead of int for bool function > will get the same output under x86_64. If the output is same then there is no reason to change it. > In our case, for gcc 4.8, using bool instead of int for bool function > will get a little better output under x86_64. I had a different impression and the fast path code had more instructions. But anyway, is there really a strong reason to change those return values in the first place? Isn't that just a pointless code churn? -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>