public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew MacLeod <amacleod@redhat.com>
To: Aldy Hernandez <aldyh@redhat.com>,
	Jeff Law <jeffreyalaw@gmail.com>,
	GCC patches <gcc-patches@gcc.gnu.org>
Cc: Richard Biener <richard.guenther@gmail.com>,
	Martin Sebor <msebor@redhat.com>
Subject: Re: [PATCH 1/2] Implement basic block path solver.
Date: Fri, 2 Jul 2021 09:16:48 -0400	[thread overview]
Message-ID: <408f5a69-952f-3e66-44df-54048df82d2d@redhat.com> (raw)
In-Reply-To: <916a4bf3-a60a-29b6-d013-06135e0d25aa@redhat.com>

On 7/2/21 4:13 AM, Aldy Hernandez wrote:
>>> +
>>> +// Return the range of STMT as it would be seen at the end of the path
>>> +// being analyzed.  Anything but the final conditional in a BB will
>>> +// return VARYING.
>>> +
>>> +void
>>> +path_solver::range_in_path (irange &r, gimple *stmt)
>>> +{
>>> +  if (gimple_code (stmt) == GIMPLE_COND && fold_range (r, stmt, this))
>>> +    return;
>>> +
>>> +  r.set_varying (gimple_expr_type (stmt));
>>> +}
>> Not objecting to anything here other than to note that I think we 
>> have cases where there's a COND_EXPR on the RHS of statements within 
>> a block.  We're (in general) not handling those well in DOM or jump 
>> threading.
>
> I guess I can put that on my TODO list :). 

note that we are no longer in the days of range-ops only processing...   
fold_range handles COND_EXPR (and every other kind of stmt)  just fine.

Andrew


  reply	other threads:[~2021-07-02 13:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 16:21 [PATCH 0/2] Ranger-based backwards threader implementation Aldy Hernandez
2021-06-28 16:21 ` [PATCH 1/2] Implement basic block path solver Aldy Hernandez
2021-07-01 22:20   ` Jeff Law
2021-07-02  8:13     ` Aldy Hernandez
2021-07-02 13:16       ` Andrew MacLeod [this message]
2021-07-15 14:55         ` Aldy Hernandez
2021-07-26 19:10       ` Jeff Law
2021-07-27  9:58         ` Aldy Hernandez
2021-07-27 15:18           ` Jeff Law
2021-06-28 16:21 ` [PATCH 2/2] Backwards jump threader rewrite with ranger Aldy Hernandez
2021-07-05 15:39   ` Aldy Hernandez
2021-07-15 14:57     ` Aldy Hernandez
2021-07-26 12:43       ` Aldy Hernandez
2021-07-28 14:32       ` Jeff Law
2021-07-28 14:51         ` Aldy Hernandez
2021-07-28 15:29           ` Martin Sebor
2021-06-28 23:19 ` [PATCH 0/2] Ranger-based backwards threader implementation Martin Sebor
2021-06-29 10:27   ` Aldy Hernandez
2021-06-29 21:22     ` Martin Sebor
2021-06-30  6:08       ` 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=408f5a69-952f-3e66-44df-54048df82d2d@redhat.com \
    --to=amacleod@redhat.com \
    --cc=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=msebor@redhat.com \
    --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).