| Submitter | Maxim Kuvyrkov |
|---|---|
| Date | June 23, 2010, 8:29 p.m. |
| Message ID | <4C226EC0.8020204@codesourcery.com> |
| Download | mbox | patch |
| Permalink | /patch/56713/ |
| State | New |
| Headers | show |
Comments
On Wed, Jun 23, 2010 at 1:29 PM, Maxim Kuvyrkov <maxim@codesourcery.com> wrote: > GCC Internals still mentions a restriction from egcs era when new pseudos > were not allowed to be generated after flow. This is not longer true and a > number of architectures successfully generate new pseudos in their > define_splits. This restriction was removed when flow.c was removed in January 2006; it is not just an egcs era restriction. I would remove the reference to define_expand here because both have the same restriction after (and during) reload. Thanks, Andrew Pinski
On 06/23/10 14:39, Andrew Pinski wrote: > On Wed, Jun 23, 2010 at 1:29 PM, Maxim Kuvyrkov<maxim@codesourcery.com> wrote: > >> GCC Internals still mentions a restriction from egcs era when new pseudos >> were not allowed to be generated after flow. This is not longer true and a >> number of architectures successfully generate new pseudos in their >> define_splits. >> > This restriction was removed when flow.c was removed in January 2006; > it is not just an egcs era restriction. > > I would remove the reference to define_expand here because both have > the same restriction after (and during) reload. > Note that over time we've pushed the line at which no new pseudos could be created from the end of flow to a point inside IRA. My work pushes the line to the beginning of reload. Jeff
Patch
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index c37bb03..2ea4480 100644 --- a/gcc/doc/md.texi +++ b/gcc/doc/md.texi @@ -6033,8 +6033,7 @@ are specified for @code{define_expand} (@pxref{Expander Definitions}) and are executed before the new RTL is generated to prepare for the generated code or emit some insns whose pattern is not fixed. Unlike those in @code{define_expand}, however, these statements must not -generate any new pseudo-registers. Once reload has completed, they also -must not allocate any space in the stack frame. +allocate any space in the stack frame once reload has completed. Patterns are matched against @var{insn-pattern} in two different circumstances. If an insn needs to be split for delay slot scheduling