This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: pass_stdarg problem when run after pass_lim
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Tom de Vries <Tom_deVries at mentor dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 29 Jan 2015 20:07:47 +0100
- Subject: Re: pass_stdarg problem when run after pass_lim
- Authentication-results: sourceware.org; auth=none
- References: <54CA6BB1 dot 10502 at mentor dot com> <20150129172535 dot GN1746 at tucnak dot redhat dot com> <75456A44-23AD-40ED-B24A-31CB5EDB8FB8 at gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Jan 29, 2015 at 07:44:29PM +0100, Richard Biener wrote:
> On January 29, 2015 6:25:35 PM CET, Jakub Jelinek <jakub@redhat.com> wrote:
> >On Thu, Jan 29, 2015 at 06:19:45PM +0100, Tom de Vries wrote:
> >> consider attached patch, which adds pass_lim after fre1 (a
> >simplification of
> >> my oacc kernels patch series).
> >>
> >> The included testcase lim-before-stdarg.c fails.
> >>
> >> The first sign of trouble is in lim-before-stdarg.c.088t.stdarg
> >(attached):
> >> ...
> >> gen_rtvec: va_list escapes 0, needs to save 0 GPR units and 0 FPR
> >units.
> >> ...
> >>
> >> Because of the 'need to save 0 GPRs units', at expand no prologue is
> >> generated to dump the varargs in registers onto stack.
> >
> >The stdarg pass can't grok too heavy optimizations, so if at all
> >possible,
> >don't schedule such passes early, and if you for some reason do, avoid
> >optimizing in there the va_list related accesses. I'm afraid that is
> >the
> >only recommendation I can give here for that.
>
> The other possibility (Matz has patches for that) is to delay vaarg lowering currently done by gimplification and combine it with the stdarg pass.
Yeah, that should work too. But stage1 material probably.
Jakub