On Tue, Nov 24, 2015 at 12:53 AM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Mon, Nov 23, 2015 at 7:22 PM, Patrick Palka <patr...@parcs.ath.cx> wrote: >> On Mon, Nov 23, 2015 at 3:53 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>> On Mon, Nov 23, 2015 at 1:57 AM, Richard Biener >>> <richard.guent...@gmail.com> wrote: >>>> On Sat, Nov 21, 2015 at 12:46 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>>> On Fri, Nov 20, 2015 at 2:17 PM, Jason Merrill <ja...@redhat.com> wrote: >>>>>> On 11/20/2015 01:52 PM, H.J. Lu wrote: >>>>>>> >>>>>>> On Tue, Nov 17, 2015 at 4:22 AM, Richard Biener >>>>>>> <richard.guent...@gmail.com> wrote: >>>>>>>> >>>>>>>> On Tue, Nov 17, 2015 at 12:01 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Empty record should be returned and passed the same way in C and C++. >>>>>>>>> This patch adds LANG_HOOKS_EMPTY_RECORD_P for C++ empty class, which >>>>>>>>> defaults to return false. For C++, LANG_HOOKS_EMPTY_RECORD_P is >>>>>>>>> defined >>>>>>>>> to is_really_empty_class, which returns true for C++ empty classes. >>>>>>>>> For >>>>>>>>> LTO, we stream out a bit to indicate if a record is empty and we store >>>>>>>>> it in TYPE_LANG_FLAG_0 when streaming in. get_ref_base_and_extent is >>>>>>>>> changed to set bitsize to 0 for empty records. Middle-end and x86 >>>>>>>>> backend are updated to ignore empty records for parameter passing and >>>>>>>>> function value return. Other targets may need similar changes. >>>>>>>> >>>>>>>> >>>>>>>> Please avoid a new langhook for this and instead claim a bit in >>>>>>>> tree_type_common >>>>>>>> like for example restrict_flag (double-check it is unused for >>>>>>>> non-pointers). >>>>>>> >>>>>>> >>>>>>> There is no bit in tree_type_common I can overload. restrict_flag is >>>>>>> checked for non-pointers to issue an error when it is used on >>>>>>> non-pointers: >>>>>>> >>>>>>> >>>>>>> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/template/qualttp20.C:19:38: >>>>>>> error: ‘__restrict__’ qualifiers cannot be applied to ‘AS::L’ >>>>>>> typedef typename T::L __restrict__ r;// { dg-error "'__restrict__' >>>>>>> qualifiers cannot" "" } >>>>>> >>>>>> >>>>>> The C++ front end only needs to check TYPE_RESTRICT for this purpose on >>>>>> front-end-specific type codes like TEMPLATE_TYPE_PARM; cp_type_quals >>>>>> could >>>>>> handle that specifically if you change TYPE_RESTRICT to only apply to >>>>>> pointers. >>>>>> >>>>> >>>>> restrict_flag is also checked in this case: >>>>> >>>>> [hjl@gnu-6 gcc]$ cat x.i >>>>> struct dummy { }; >>>>> >>>>> struct dummy >>>>> foo (struct dummy __restrict__ i) >>>>> { >>>>> return i; >>>>> } >>>>> [hjl@gnu-6 gcc]$ gcc -S x.i -Wall >>>>> x.i:4:13: error: invalid use of ‘restrict’ >>>>> foo (struct dummy __restrict__ i) >>>>> ^ >>>>> x.i:4:13: error: invalid use of ‘restrict’ >>>>> [hjl@gnu-6 gcc]$ >>>>> >>>>> restrict_flag can't also be used to indicate `i' is an empty record. >>>> >>>> I'm sure this error can be done during parsing w/o relying on >>>> TYPE_RESTRICT. >>>> >>>> But well, use any other free bit (but do not enlarge >>>> tree_type_common). Eventually >>>> you can free up a bit by putting sth into type_lang_specific currently >>>> using bits >>>> in tree_type_common. >>> >>> There are no bits in tree_type_common I can move. Instead, >>> this patch overloads side_effects_flag in tree_base. Tested on >>> Linux/x86-64. OK for trunk? >>> >> >> Hi, >> >> Coincidentally a few months ago I was experimenting with making >> empty-struct function arguments zero-cost (and thus making them behave >> the same way as in GNU C). My approach (patch attached) was to assign >> empty-struct arguments to a virtual register (instead of on the stack >> or to a hard register) during RTL call expansion. These >> virtual-register assignments would then be trivially DCE'd later. >> This approach seemed to work surprisingly well with minimal code >> changes. I wonder what >> your thoughts are on this approach.. > > I don't think it works for C++ class. empty_record_or_union_type_p > missed: > > for (binfo = TYPE_BINFO (type), i = 0; > BINFO_BASE_ITERATE (binfo, i, base_binfo); ++i) > if (!is_really_empty_class (BINFO_TYPE (base_binfo))) > return false;
Yeah, your TYPE_EMPTY_RECORD flag covers more instances of empty structs than this predicate does. > > Does it work with variable argument list? Did you run GCC > testsuite for both i686 and x86-64? Hmm, I don't think it works with variable argument lists, at least not perfectly. And I just finished running the testsuite on x86-64 and observed a failure in struct-layout-1.exp which makes no sense to me. Now I remember why I didn't pursue this change any further.