public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Guenther <richard.guenther@gmail.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	Richard Henderson <rth@redhat.com>
Subject: Re: [patch] 19/n: trans-mem: middle end/misc patches (LAST PATCH)
Date: Mon, 07 Nov 2011 09:48:00 -0000	[thread overview]
Message-ID: <CAFiYyc0k5ui-JA=PPbEMdRjhDmACP44B3ja12BVJk3JP8GOpjA@mail.gmail.com> (raw)
In-Reply-To: <4EB6D797.4070309@redhat.com>

On Sun, Nov 6, 2011 at 7:53 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
> [rth, more comments for you below]
>
> On 11/04/11 04:14, Richard Guenther wrote:
>
>>>    new_version = cgraph_create_node (new_decl);
>>>
>>> -   new_version->analyzed = true;
>>> +   new_version->analyzed = old_version->analyzed;
>>
>> Hm?  analyzed means "with body", sure you have a body if you clone.
>>
>>>    new_version->local = old_version->local;
>>>    new_version->local.externally_visible = false;
>>>    new_version->local.local = true;
>>> @@ -2294,6 +2294,7 @@ cgraph_copy_node_for_versioning (struct
>>>    new_version->rtl = old_version->rtl;
>>>    new_version->reachable = true;
>>>    new_version->count = old_version->count;
>>> +   new_version->lowered = true;
>>
>> OTOH this isn't necessary true.  cgraph exists before lowering.
>
> I don't understand what you want me to do on either of these two comments.
>  Could you elaborate?

Do not push new_version->lowered setting into the core routine but keep
it at the callers.

>>> +  /* TM pure functions should not get inlined if the outer function is
>>> +     a TM safe function.  */
>>> +  else if (flag_tm
>>
>> Please move flag checks into the respective prediates.  Any reason
>> why the is_tm_pure () predicate wouldn't already do the correct thing
>> with !flag_tm?
>
> Done.
>
>>> +  /* Map gimple stmt to tree label (or list of labels) for transaction
>>> +     restart and abort.  */
>>> +  htab_t GTY ((param_is (struct tm_restart_node))) tm_restart;
>>> +
>>
>> As this maps 'gimple' to tree shouldn't this go to fn->gimple_df instead?
>> That way you avoid growing generic struct function.  Or in to eh_status,
>> if that looks like a better fit.
>
> Done.
>
>>> +  /* Mark all calls that can have a transaction restart.  */
>>
>> Why isn't this done when we expand the call?  This walking of the
>> RTL sequence looks like a hack (an easy one, albeit).
>>
>>> +  if (cfun->tm_restart&&  is_gimple_call (stmt))
>>> +    {
>>> +      struct tm_restart_node dummy;
>>> +      void **slot;
>>> +
>>> +      dummy.stmt = stmt;
>>> +      slot = htab_find_slot (cfun->tm_restart,&dummy, NO_INSERT);
>>> +      if (slot)
>>> +       {
>>> +         struct tm_restart_node *n = (struct tm_restart_node *) *slot;
>>> +         tree list = n->label_or_list;
>>> +         rtx insn;
>>> +
>>> +         for (insn = next_real_insn (last); !CALL_P (insn);
>>> +              insn = next_real_insn (insn))
>>> +           continue;
>>> +
>>> +         if (TREE_CODE (list) == LABEL_DECL)
>>> +           add_reg_note (insn, REG_TM, label_rtx (list));
>>> +         else
>>> +           for (; list ; list = TREE_CHAIN (list))
>>> +             add_reg_note (insn, REG_TM, label_rtx (TREE_VALUE (list)));
>>> +       }
>>> +    }
>
> I can certainly move this to expand_call_stmt() if you prefer.  Do you have
> an objection to the RTL walk?  This isn't my code, but I'm open to
> suggestions on an alternative to implement.

It just catched my eye...  moving it to expand_call_stmt would be nice
indeed, but I was suggesting to add that note where we produce the
CALL rtx, not sure if that's reasonably straight-forward (I suppose there
was a reason to go with the hack above ...).

Richard.

  parent reply	other threads:[~2011-11-07  9:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-03 19:58 Aldy Hernandez
2011-11-04 11:22 ` Richard Guenther
2011-11-06 19:07   ` Aldy Hernandez
2011-11-06 20:47     ` Richard Henderson
2011-11-06 22:01       ` Aldy Hernandez
2011-11-07  4:25       ` Aldy Hernandez
2011-11-07  7:53       ` Aldy Hernandez
2011-11-07  9:56         ` Richard Guenther
2011-11-07 15:54           ` Aldy Hernandez
2011-11-07 16:08             ` Richard Guenther
2011-11-07 17:12               ` Aldy Hernandez
2011-11-06 21:50     ` Richard Henderson
2011-11-07  9:48     ` Richard Guenther [this message]
2011-11-07 16:08       ` Aldy Hernandez
2011-11-07 16:14         ` Richard Henderson
2011-11-07 16:23           ` Aldy Hernandez
2011-11-07 16:32             ` Richard Henderson
2011-11-07 16:11       ` Richard Henderson
2011-11-07 17:45       ` Aldy Hernandez
2011-11-07 20:57         ` Aldy Hernandez

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='CAFiYyc0k5ui-JA=PPbEMdRjhDmACP44B3ja12BVJk3JP8GOpjA@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rth@redhat.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).