Joern, Thanks for your valuable feedback! This is only a RFC, and I will send out formal patch along with ChangLog later on.
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. Thanks, -Jiangning > -----Original Message----- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] > On Behalf Of Joern Rennecke > Sent: Tuesday, July 26, 2011 10:33 AM > To: Jiangning Liu > Cc: g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; vmaka...@redhat.com; > dje....@gmail.com; Richard Henderson; Ramana Radhakrishnan; 'Ramana > Radhakrishnan' > Subject: RE: [RFC] Add middle end hook for stack red zone size > > Quoting Jiangning Liu <jiangning....@arm.com>: > > > Hi, > > > > One month ago, I sent out this RFC to *gcc-patches* mail list, but I > > didn't receive any response yet. So I'm forwarding this mail to > > *gcc* mail list. Can anybody here really give feedback to me? > > Well, I couldn't approve any patch, but I can point out some issues with your > patch. > > First, it's missing a ChangeLog, and you don't state how you have tested it. > And regarding the code in sched_analyze_1, I think you'll get false positives > with > alloca, and false negatives when registers are involved to compute offsets or > to > restore the stack pointer from. > > FWIW, I think generally blunt scheduling barriers should be avoided, and > instead > the dependencies made visible to the scheduler. > E.g., I've been working with another architecture with a redzone, where at > -fno- > omit-frame-pointer, the prologue can put pretend_args into the redzone, then > after > stack adjustment and frame allocation, these arguments are accessed via the > frame > pointer. > > With the attached patchlet, alias analysis works for this situation too, so > no blunt > scheduling block is required. > > Likewise, with stack adjustments, they should not affect scheduling in > general, but > be considered to clobber the part of the frame that is being exposed to > interrupt > writes either before or after the adjustment. > At the moment, each port that wants to have such selective scheduling > blockages > has to define a stack_adjust pattern with a memory clobber in a parallel, > with a > memref that shows the high water mark of possible interrupt stack writes. > Prima facia it would seem convenient if you only had to tell the middle-end > about > the redzone size, and it could figure out the implicit clobbers when the > stack is > changed. However, when a big stack adjustment is being made, or the stack is > realigned, or restored from the frame pointer / another register where it was > saved due to realignment, the adjustment is not so obvious. I'm not sure if > you can > actually create an robust interface that's simpler to use than putting the > right > memory clobber in the stack adjust pattern. Note also that the redzone size > can > vary from function to function depending on ABI-altering attributes, in > particular > for interrupt functions, which can also have different incoming and outgoing > redzone sizes. Plus, you can have an NMI / reset handler which can use the > stack > like an ordinary address register.
