https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #17 from Jeffrey A. Law ---
Author: law
Date: Fri Dec 15 22:11:06 2017
New Revision: 255724
URL: https://gcc.gnu.org/viewcvs?rev=255724&root=gcc&view=rev
Log:
PR tree-optimization/81165
* tree-ssa-threadupdate.c (uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #16 from Alexandre Oliva ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00376.html
(before seeing Jeff's comments)
Anyway, I think this is simple enough to go into 8. It isn't hard to add
caching, should we find i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #15 from Jeffrey A. Law ---
Yea, I just looked and it's somewhat painful to do because of how threading
works. We walk statements forward and stop when we hit the limit. But DCE
analysis is easier to formulate as a backwards walk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #14 from Alexandre Oliva ---
Created attachment 42802
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42802&action=edit
patch, second try (following backlinks from dead uses to maybe-dead defs)
Here's an alternate patch that get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #12 from Jeffrey A. Law ---
In general we can't know if we're going to have a single argument PHI after
threading. If the block has multiple preds that thread to the same final
destination, then we create a single copy and vector al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #11 from rguenther at suse dot de ---
On December 4, 2017 6:55:02 PM GMT+01:00, law at redhat dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
>
>Jeffrey A. Law changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #9 from Alexandre Oliva ---
The reason dom doesn't duplicate the loop entry test is that the additional phi
node grows it past the max-jump-thread-duplication-stmts limit. Compiling with
--param max-jump-thread-duplication-stmts=16 w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #8 from Alexandre Oliva ---
It is combine that simplifies a compare of _9 (aka t1) with 1: it knows _9 is
either -1 or 0 from the &1 followed by -1, so it can't be equal to 1. From
that simplification, others follow, and the loop exi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #7 from Alexandre Oliva ---
it may very well be the case that it is gcc7 that's buggy in optimizing out the
loop. after all, there is a divide-by-x0 in the loop entry test and, save for
global optimizations, the compiler couldn't tel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #6 from Marc Glisse ---
(In reply to Richard Biener from comment #5)
> we miss to optimize (int)((short int)((unsigned short) x1.1_4 ^ 8) & 1) to
> (int)(x1.1_4 & 1) as well.
(untested)
+/* (X |^ 8) & 1 --> X & 1 */
+(for op (bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.0
Summary|Regression in GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|
17 matches
Mail list logo
