From: Richard Biener <rguenther@suse.de>
To: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Cc: Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org>,
Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Move negative stride bias out of dr_misalignment
Date: Tue, 26 Oct 2021 14:10:05 +0200 (CEST) [thread overview]
Message-ID: <qrqppqpr-ns17-4s20-95so-s9o87sn4n8os@fhfr.qr> (raw)
In-Reply-To: <5916DAE9-2B77-4AA7-9676-BA2A8538A219@gmail.com>
On Tue, 26 Oct 2021, Bernhard Reutner-Fischer wrote:
> On 26 October 2021 11:19:44 CEST, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
>
>
> >@@ -2010,6 +2010,7 @@ get_negative_load_store_type (vec_info *vinfo,
> > if (dump_enabled_p ())
> > dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> > "negative step but alignment required.\n");
> >+ *poffset = 0;
> > return VMAT_ELEMENTWISE;
> > *poffset = 0;
> > }
>
> I think you cannot really diagnose these, they would trigger a lot, in each early return, no?
> Or would we see that there are unreachable, non artificial stmts in the same block after a return?
> Somebody could experiment with diagnosing each and every DCEd stmt (!artificial, nondebug) but I would expect that hell breaks loose..
> cheers,
[I fixed the issue before pushing this patch btw]
I agree in general, where I would diagnose this is when we build the
CFG I would diagnose unreachable blocks - the above does not have
any path to the second *poffset store. Like with the prototype patch
below we warn for
int *p;
int foo()
{
return 0;
*p = 0;
}
> ./cc1 -quiet t.c
t.c: In function 'foo':
t.c:5:3: warning: statement is not reachable
5 | *p = 0;
| ^~
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index b3a27bcd17c..2de661ba35d 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -374,6 +374,22 @@ execute_build_cfg (void)
fprintf (dump_file, "Scope blocks:\n");
dump_scope_blocks (dump_file, dump_flags);
}
+
+ find_unreachable_blocks ();
+ basic_block bb;
+ FOR_EACH_BB_FN (bb, cfun)
+ if (!(bb->flags & BB_REACHABLE))
+ for (gimple_stmt_iterator gsi = gsi_start_bb (bb); !gsi_end_p
(gsi);
+ gsi_next (&gsi))
+ {
+ if (gimple_location (gsi_stmt (gsi)) != UNKNOWN_LOCATION)
+ warning_at (gimple_location (gsi_stmt (gsi)), 0,
+ "statement is not reachable");
+ /* ??? Mark blocks reachable from here. And even better make
+ sure to process entries to unreachable regions first. */
+ break;
+ }
+
cleanup_tree_cfg ();
bb_to_omp_idx.release ();
next prev parent reply other threads:[~2021-10-26 12:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-26 9:19 Richard Biener
2021-10-26 11:48 ` Bernhard Reutner-Fischer
2021-10-26 12:10 ` Richard Biener [this message]
2021-10-26 12:25 ` Bernhard Reutner-Fischer
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=qrqppqpr-ns17-4s20-95so-s9o87sn4n8os@fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=rep.dot.nop@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).