This is the mail archive of the
mailing list for the GCC project.
Re: pass_stdarg problem when run after pass_lim
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>,Tom de Vries <Tom_deVries at mentor dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 29 Jan 2015 19:44:29 +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>
On January 29, 2015 6:25:35 PM CET, Jakub Jelinek <email@example.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
>> 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
>> gen_rtvec: va_list escapes 0, needs to save 0 GPR units and 0 FPR
>> 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
>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
>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.