It almost seems as if you think that the compiler optimises at the C level. It's quite reasonable to assume that optimising compilers do a better job when you
do break up large functions (using "helper functions") because optimisation doesn't generally happen at the C level but on an intermediate (abstracted) representation of whatever you write (see
Intermediate representation - Wikipedia). Besides that, large functions are difficult to maintain and hard to understand for humans. Most optimisations that have any relevance depend on choosing the correct algorithm in the first place (and in some cases using keywords like restrict so that the compiler can optimise more aggressively, for example.
restrict - Wikipedia Don't bother with register in general... the compiler will use a register if it makes sense anyhow). Doing stuff like you're suggesting is not just premature optimisation, it might be doing the exact opposite of what you're trying to achieve.
I guess an example (maybe not a good one) similar to what you think you're doing is a project I was working on last year. A co-worker submitted a cunningly constructed micro-optimised function with a scary comment saying I should not rearrange things because it was carefully optimised to minimise x86 cache misses and that it'd fit in the pipeline or some mumbo jumbo. The problem is that we were prototyping on x86 and the actual target was ARM. So, of course the carefully constructed function was BS, the ARM code generated was not optimal and the compiler already did a better job. If it's not clear by now: I hate micro-optimisations or giving hints to the compiler (apart from well-defined hints like restrict and inline) because in 99.9% of cases I've come across the compiler does a better job. Write clear code, use the correct algorithm, break down large functions and in general the compiler will do a very good job.