This is the mail archive of the
mailing list for the GCC project.
RE: [RFC] Add middle end hook for stack red zone size
- From: "Jiangning Liu" <jiangning dot liu at arm dot com>
- To: "'Joern Rennecke'" <amylaar at spamcop dot net>
- Cc: <gcc at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>, <vmakarov at redhat dot com>, <dje dot gcc at gmail dot com>, "Richard Henderson" <rth at redhat dot com>, "Ramana Radhakrishnan" <Ramana dot Radhakrishnan at arm dot com>, "'Ramana Radhakrishnan'" <ramana dot radhakrishnan at linaro dot org>
- Date: Mon, 1 Aug 2011 11:44:04 +0800
- Subject: RE: [RFC] Add middle end hook for stack red zone size
- References: <4e255312.0a852b0a.528d.6933SMTPIN_ADDED@mx.google.com> <CACUk7=WsaUN+TUw7rb8-o1EukoaCMrAh8bFJM6832LtRmfkofg@mail.gmail.com> <001e01cc4b33$6d3818f0$47a84ad0$@firstname.lastname@example.org> <email@example.com>
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.
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]
> On Behalf Of Joern Rennecke
> Sent: Tuesday, July 26, 2011 10:33 AM
> To: Jiangning Liu
> Cc: firstname.lastname@example.org; email@example.com; firstname.lastname@example.org;
> email@example.com; Richard Henderson; Ramana Radhakrishnan; 'Ramana
> Subject: RE: [RFC] Add middle end hook for stack red zone size
> Quoting Jiangning Liu <firstname.lastname@example.org>:
> > 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
> 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.