RE: [RFC] Add middle end hook for stack red zone size
Jiangning Liu <jiangning.liu <at> arm.com>
2011-08-01 03:44:04 GMT
Thanks for your valuable feedback! This is only a RFC, and I will send out formal patch along with ChangLog
Basically, my patch is only to add new dependence in scheduler, and it only blocks some instruction
movements, so it is NO RISK to compiler correctness. For whatever stack pointer changes you gave in
different scenarios, the current code base should already work. My patch intends neither to replace old
dependences, nor maximize the scheduler capability due to the existence of red zone in stack. It is only to
block the memory access moving over stack pointer adjustment if distance is beyond red zone size, which is
an OS requirement due to interruption existence.
Stack adjustment in epilogue is a very general usage in stack frame. It's quite necessary to solve the
general problem in middle-end rather than in back-end. Also, that old patch you attached is to solve the
data dependence between two memory accesses, but stack pointer doesn't really have data dependence with
memory access without using stack pointer, so they have different stories. Alternative solution of
without adding blunt scheduling barrier is we insert an independent pass before scheduler to create RTL
barrier by using the same interface stack_red_zone_size, but it would really be an over-design, if we add
a new pass only for this *small* functionality.
In my patch, *abs* of offset is being used, so you are right that it's possible to get false positive to be too
conservative, but there won't exist false negative, because my code would only add new dependences.
Since the compilation is based on function, it would be OK if red zone size varies due to different ABI. Could
you please tell me exactly on what system being supported by GCC red zone size can be different for incoming
and outgoing? And also how scheduler guarantee the correctness in current code base? Anyway, I don't
think my patch will break the original solution.