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.
next prev 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).