On Thu, 14 May 2015, Tom de Vries wrote: > On 12-05-15 12:04, Richard Biener wrote: > > > The fact that we have to handle this specially in both build_va_arg and > > > >gimplify_va_arg makes me wonder whether we should be dealing with all > > > this in > > > >build_va_arg already. > > > > > > > >That is, determine whether we take the address, and add the address > > > operator > > > >if so in build_va_arg already. Likewise, determine do_deref and pass that > > > as > > > >extra operand. > > That would certainly be a nice cleanup. > > I've implemented this cleanup. > > Furthermore, I realized that in expand_ifn_va_arg_1, 'do_deref == 0' disables > code: > ... > if (do_deref == integer_one_node) > ap = build_fold_indirect_ref (ap); > ... > > that has a copy in the target hook: > ... > gpr = build3 (COMPONENT_REF, TREE_TYPE (f_gpr), > build_va_arg_indirect_ref (valist), f_gpr, NULL_TREE); > valist = build_va_arg_indirect_ref (valist); > ... > > It's easier to remove that code from the few target hooks that do that, > execute the 'do_deref == 1' code unconditionally in expand_ifn_va_arg_1 and > simply remove all do_deref propagation (that also means we don't have to add > an operand to VA_ARG_EXPR). > > > Bootstrapped and reg-tested on x86_64, with and without -m32. > > Did partial build and compiled a few va_arg test-cases on the other targets. > > OK for trunk?
Ok. Thanks, Richard. > Thanks, > - Tom > > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)
