pass_stdarg problem when run after pass_lim
Tom de Vries
Tom_deVries@mentor.com
Thu Jan 29 22:20:00 GMT 2015
On 29-01-15 18:25, Jakub Jelinek wrote:
> 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.
This patch work for the example.
In pass_lim1, I get:
...
;; Function gen_rtvec (gen_rtvec, funcdef_no=1, decl_uid=1841, cgraph_uid=1,
symbol_order=1)
va_list_related_stmt_p: no simple_mem_ref
_15 = p.gp_offset;
va_list_related_stmt_p: no simple_mem_ref
_16 = p.reg_save_area;
va_list_related_stmt_p: no simple_mem_ref
p.gp_offset = _21;
va_list_related_stmt_p: no simple_mem_ref
_23 = p.overflow_arg_area;
va_list_related_stmt_p: no simple_mem_ref
p.overflow_arg_area = _25;
va_list_related_stmt_p: MOVE_IMPOSSIBLE
_15 = p.gp_offset;
va_list_related_stmt_p: MOVE_IMPOSSIBLE
_16 = p.reg_save_area;
va_list_related_stmt_p: MOVE_IMPOSSIBLE
_23 = p.overflow_arg_area;
gen_rtvec (int n)
...
Thanks,
- Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Handle-va_list-conservatively-in-pass_lim.patch
Type: text/x-patch
Size: 2156 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20150129/7a92f284/attachment.bin>
More information about the Gcc
mailing list