On 2017/2/22 上午3:20, Wols Lists wrote: > On 21/02/17 11:30, Coly Li wrote: >> On 2017/2/21 上午2:14, Wols Lists wrote: >>> On 20/02/17 08:07, Coly Li wrote: >>>> For the function pointer asignment, it is because I see a brach happens in a loop. If I use a function pointer, I can avoid redundant brach inside the loop. raid1_read_request() and raid1_write_request() are not simple functions, I don't know whether gcc may make them inline or not, so I am on the way to check the disassembled code.. >>> >>> Can you force gcc to inline or compile a function? Isn't it dangerous to >>> rely on default behaviour and assume it won't change when the compiler >>> is upgraded? >> >> I choose to trust compiler, and trust the people behind gcc. >> > I admire your faith. I seem to remember several occasions where the gcc > people added new optimisations and caused all sorts of subtle havoc with > the kernel where it relied on the old behaviour. Don't forget - the > linux kernel is one of the compiler's most demanding customers. And > don't forget also - there are quite a few people now using llvm to > compile the kernel (it may not yet be working - I think it is certainly > for simple use cases) so tests on gcc don't guarantee it'll work for > everyone ... I know the risk, but I don't think I can figure out where gcc goes wrong by myself. So I have to choose trust compiler developers. > > I think you can trace the addition of many kernel compile-time flags to > that sort of thing - disabling new optimisations. Do you suggest that I can put my eyes on kernel compiling command lines and I will find many compile-time flags which indeed disables some new gcc optimization options ? If I understand you correctly, please permit me to say this is a good point. I will notice these kind of flags, and check what they mean :-) Thanks. Coly -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
