This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [trans-mem] handle invisible references for decls (PR/47554)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Aldy Hernandez <aldyh at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 5 Feb 2011 00:26:31 +0100
- Subject: Re: [trans-mem] handle invisible references for decls (PR/47554)
- References: <4D4C5CC2.2060205@redhat.com> <4D4C61BE.9010805@redhat.com>
On Fri, Feb 4, 2011 at 9:29 PM, Richard Henderson <rth@redhat.com> wrote:
> On 02/04/2011 12:08 PM, Aldy Hernandez wrote:
>> + ? ? ?if (DECL_BY_REFERENCE (x))
>> + ? ? {
>> + ? ? ? /* Stupid GCC magic. ?In assign_params() we'll see the
>> + ? ? ? ? ?DECL_BY_REFERENCE and put the whole thing in a register,
>> + ? ? ? ? ?so we can't instrument this by calculating &<retval>. ?We
>> + ? ? ? ? ?will see the resulting INDIRECT_REF elsewhere and
>> + ? ? ? ? ?instrument that. ?See... this is why GCC hackers will
>> + ? ? ? ? ?always have a job, cause nobody understands this and
>> + ? ? ? ? ?takes too long to rewrite it. ?*/
>> + ? ? ? return false;
>
> Ha ha.
>
> A better comment might be
>
> ?/* ??? This value is a pointer, but aggregate_value_p has been
> ? ? jigged to return true which confuses needs_to_live_in_memory.
> ? ? This ought to be cleaned up generically. ?*/
>
> Ok with that change.
>
>
> I sincerely believe that the test in aggregate_value_p is a mistake.
> We should not be lying about the fact that this value is a pointer.
> But looking at how DECL_BY_REFERENCE is used elsewhere, it'll be a
> hard one to unravel. ?And that certainly should not be done on this
> branch.
Hm, I think we fixed this on trunk and DECL_BY_REFERENCE result-decls
are now even in SSA form.
Richard.
>
> r~
>