Message ID | 4C226EC0.8020204@codesourcery.com |
---|---|
State | New |
Headers | show |
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
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