From: "H.J. Lu" <hjl.tools@gmail.com>
To: Patrick Palka <patrick@parcs.ath.cx>
Cc: Richard Biener <richard.guenther@gmail.com>,
Jason Merrill <jason@redhat.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Add LANG_HOOKS_EMPTY_RECORD_P for C++ empty class
Date: Tue, 24 Nov 2015 06:00:00 -0000 [thread overview]
Message-ID: <CAMe9rOpc0mPZx95Ns554aJpWAodNXguiAH7kVC+56VQf4MbyxQ@mail.gmail.com> (raw)
In-Reply-To: <CA+C-WL-edsY9rWzE09XGs6Vhgp9Xn2KR50wJ3vDpwKkVh9fbZw@mail.gmail.com>
On Mon, Nov 23, 2015 at 7:22 PM, Patrick Palka <patrick@parcs.ath.cx> wrote:
> On Mon, Nov 23, 2015 at 3:53 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Nov 23, 2015 at 1:57 AM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Sat, Nov 21, 2015 at 12:46 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Fri, Nov 20, 2015 at 2:17 PM, Jason Merrill <jason@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.guenther@gmail.com> wrote:
>>>>>>>
>>>>>>> On Tue, Nov 17, 2015 at 12:01 PM, H.J. Lu <hjl.tools@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;
Does it work with variable argument list? Did you run GCC
testsuite for both i686 and x86-64?
--
H.J.
next prev parent reply other threads:[~2015-11-24 5:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-17 11:01 H.J. Lu
2015-11-17 12:22 ` Richard Biener
2015-11-20 18:52 ` H.J. Lu
2015-11-20 22:17 ` Jason Merrill
2015-11-20 22:24 ` Jason Merrill
2015-11-20 23:47 ` H.J. Lu
2015-11-23 9:59 ` Richard Biener
2015-11-23 20:54 ` H.J. Lu
2015-11-24 3:48 ` Patrick Palka
2015-11-24 6:00 ` H.J. Lu [this message]
2015-11-24 6:10 ` Andrew Pinski
2015-11-24 12:52 ` H.J. Lu
2015-11-24 16:31 ` Patrick Palka
2015-11-24 16:59 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMe9rOpc0mPZx95Ns554aJpWAodNXguiAH7kVC+56VQf4MbyxQ@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=patrick@parcs.ath.cx \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).