On Thu, Apr 16, 2015 at 4:55 PM, Richard Biener <rguent...@suse.de> wrote: > On Thu, 16 Apr 2015, Tom de Vries wrote: > >> [stage1 ping^2] >> On 10-03-15 16:30, Tom de Vries wrote: >> > [stage1 ping] >> > On 22-02-15 14:13, Tom de Vries wrote: >> > > On 19-02-15 14:03, Richard Biener wrote: >> > > > On Thu, 19 Feb 2015, Tom de Vries wrote: >> > > > >> > > > > On 19-02-15 11:29, Tom de Vries wrote: >> > > > > > Hi, >> > > > > > >> > > > > > I'm posting this patch series for stage1: >> > > > > > - 0001-Disable-lang_hooks.gimplify_expr-in-free_lang_data.patch >> > > > > > - 0002-Add-gimple_find_sub_bbs.patch >> > > > > > - 0003-Factor-optimize_va_list_gpr_fpr_size-out-of-pass_std.patch >> > > > > > - 0004-Handle-internal_fn-in-operand_equal_p.patch >> > > > > > - 0005-Postpone-expanding-va_arg-until-pass_stdarg.patch >> > > > > > >> > > > > > The patch series - based on Michael's initial patch - postpones >> > > > > > expanding >> > > > > > va_arg >> > > > > > until pass_stdarg, which makes pass_stdarg more robust. >> > > > > > >> > > > > > Bootstrapped and reg-tested on x86_64 using all languages, with >> > > > > > unix/ and >> > > > > > unix/-m32 testing. >> > > > > > >> > > > > > I'll post the patches in reply to this email. >> > > > > > >> > > > > >> > > > > This patch postpones expanding va_arg until pass_stdarg. >> > > > > >> > > > > We add a new internal function IFN_VA_ARG. During gimplification, we >> > > > > map >> > > > > VA_ARG_EXPR onto a CALL_EXPR with IFN_VA_ARG, which is then >> > > > > gimplified >> > > > > in to a >> > > > > gimple_call. At pass_stdarg, we expand the IFN_VA_ARG gimple_call >> > > > > into >> > > > > actual >> > > > > code. >> > > > > >> > > > > There are a few implementation details worth mentioning: >> > > > > - passing the type beyond gimplification is done by adding a NULL >> > > > > pointer- >> > > > > to-type to IFN_VA_ARG. >> > > > > - there is special handling for IFN_VA_ARG that would be most suited >> > > > > to be >> > > > > placed in gimplify_va_arg_expr. However, that function lacks the >> > > > > scope for >> > > > > the special handling, so it's placed awkwardly in >> > > > > gimplify_modify_expr. >> > > > > - there's special handling in case the va_arg type is variable-sized. >> > > > > gimplify_modify_expr adds a WITH_SIZE_EXPR to the CALL_EXPR >> > > > > IFN_VA_ARG for >> > > > > variable-sized types. However, this is gimplified into a >> > > > > gimple_call which >> > > > > does not have the possibility to wrap it's result in a >> > > > > WITH_SIZE_EXPR. So >> > > > > we're adding the size argument of the WITH_SIZE_EXPR as argument >> > > > > to >> > > > > IFN_VA_ARG, and at expansion in pass_stdarg, wrap the result of >> > > > > the >> > > > > gimplification of IFN_VA_ARG in a WITH_SIZE_EXPR, such that the >> > > > > subsequent >> > > > > gimplify_assign will generate a memcpy if necessary. >> > > > > - when gimplifying the va_arg argument ap, it may not be addressable. >> > > > > So >> > > > > gimplification will generate a copy ap.1 = ap, and use &ap.1 as >> > > > > argument. >> > > > > This means that we have to copy back the ap.1 value to ap after >> > > > > IFN_VA_ARG. >> > > > > The copy is classified by the va_list_gpr/fpr_size optimization as >> > > > > an >> > > > > escape, so it inhibits optimization. The tree-ssa/stdarg-2.c f15 >> > > > > update is >> > > > > because of that. >> > > > > >> > > > > OK for stage1? >> > > > >> > > > Looks mostly good, though it looks like with -O0 this doesn't delay >> > > > lowering of va-arg and thus won't "fix" offloading. Can you instead >> > > > introduce a PROP_gimple_lva, provide it by the stdarg pass and add >> > > > a pass_lower_vaarg somewhere where pass_lower_complex_O0 is run >> > > > that runs of !PROP_gimple_lva (and also provides it), and require >> > > > PROP_gimple_lva by pass_expand? (just look for PROP_gimple_lcx for >> > > > the complex stuff to get an idea what needs to be touched) >> > > > >> > > >> > > Updated according to comments. >> > > >> > > Furthermore (having updated the patch series to recent trunk), I'm >> > > dropping the >> > > ACCEL_COMPILER bit in pass_stdarg::gate. AFAIU the comment there relates >> > > to this >> > > patch. >> > > >> > > Retested as before. >> > > >> > > OK for stage1? >> > > >> > >> > Ping. >> >> Ping again. >> >> Patch originally posted at: >> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01332.html . > > Ok. > > Thanks, > Richard. > >> Thanks, >> - Tom >> >> > > Btw, I'm wondering if as run-time optimization we can tentatively set >> > > PROP_gimple_lva at the start of the gimple pass, and unset it in >> > > gimplify_va_arg_expr. That way we would avoid the loop in >> > > expand_ifn_va_arg_1 >> > > (over all bbs and gimples) in functions without va_arg. >> > > >> > >> > Taken care of in follow-up patch 5b.
Hi, This patch causes stdarg test failure on aarch64 for both linux and elf variants. Seems wrong code is generated. FAIL: gcc.c-torture/execute/stdarg-1.c -O0 execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O1 execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O2 execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O3 -fomit-frame-pointer execution test FAIL: gcc.c-torture/execute/stdarg-1.c -O3 -g execution test FAIL: gcc.c-torture/execute/stdarg-1.c -Os execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O0 execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O1 execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O2 execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O3 -fomit-frame-pointer execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gcc.c-torture/execute/va-arg-11.c -O3 -g execution test FAIL: gcc.c-torture/execute/va-arg-11.c -Os execution test It may also causes ICE on arm-none-linux-gnueabihf. compiler exited with status 1 output is: /projects/.../src/gcc/gcc/testsuite/gcc.c-torture/execute/stdarg-2.c: In function 'f3': /projects/.../src/gcc/gcc/testsuite/gcc.c-torture/execute/stdarg-2.c:61:1: error: incorrect sharing of tree nodes aps[4] # .MEM_5 = VDEF <.MEM_11> aps[4] = aps[4]; /projects/.../src/gcc/gcc/testsuite/gcc.c-torture/execute/stdarg-2.c:61:1: internal compiler error: verify_gimple failed 0xae4893 verify_gimple_in_cfg(function*, bool) /projects/.../src/gcc/gcc/tree-cfg.c:5136 0x9e3f2f execute_function_todo /projects/.../src/gcc/gcc/passes.c:1946 0x9e48d3 execute_todo /projects/.../src/gcc/gcc/passes.c:2003 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. FAIL: gcc.c-torture/execute/stdarg-2.c -O0 (internal compiler error) FAIL: gcc.c-torture/execute/stdarg-2.c -O0 (test for excess errors) Thanks, bin