https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #23 from Richard Biener ---
Author: rguenth
Date: Mon Nov 24 14:07:18 2014
New Revision: 218019
URL: https://gcc.gnu.org/viewcvs?rev=218019&root=gcc&view=rev
Log:
2014-11-24 Richard Biener
PR tree-optimization/63679
* tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #20 from rguenther at suse dot de ---
On Mon, 24 Nov 2014, jgreenhalgh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
>
> --- Comment #19 from jgreenhalgh at gcc dot gnu.org ---
> (In reply to rguent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #19 from jgreenhalgh at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #16)
> Certainly removing the alignment is not going to fly - we'd generate
> very bad code for strict-align targets for initializing packed
> stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #18 from rguenther at suse dot de ---
On Mon, 24 Nov 2014, belagod at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
>
> --- Comment #17 from Tejas Belagod ---
> > -
> > /* Do a block move eithe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #17 from Tejas Belagod ---
> -
> /* Do a block move either if the size is so small as to make
> each individual move a sub-unit move on average, or if it
> -is so large as to make individual moves in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #16 from rguenther at suse dot de ---
On Fri, 21 Nov 2014, jgreenhalgh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
>
> --- Comment #15 from jgreenhalgh at gcc dot gnu.org ---
> I wonder whether the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #15 from jgreenhalgh at gcc dot gnu.org ---
I wonder whether the call to can_move_by_pieces in gimplify.c is bogus. It
seems to me that gimplify.c really wants to know whether it is a good idea to
scalarize the constructor copy - nothi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #14 from jgreenhalgh at gcc dot gnu.org ---
Yes, we turn move_by_pieces off for AArch64 so we can use our own expander for
block moves. This has a number of negative side-effects where optimizers decide
that if you're not using move_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #13 from Tejas Belagod ---
(In reply to rguent...@suse.de from comment #12)
> On Fri, 21 Nov 2014, belagod at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> >
> > --- Comment #11 from Tejas Belagod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #12 from rguenther at suse dot de ---
On Fri, 21 Nov 2014, belagod at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
>
> --- Comment #11 from Tejas Belagod ---
> (In reply to Andrew Pinski from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #11 from Tejas Belagod ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Tejas Belagod from comment #7)
> > I tried this, but it still doesn't seem to fold for aarch64.
> >
> > So, here is the DOM trace for aarch64:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #10 from Richard Biener ---
Ok, so I have a patch that works until we get to try constant folding
a vector load from an array of elements. There both native_encode_expr
and fold_ctor_reference fail (the first because it doesn't handl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
Richard Biener changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #8 from Andrew Pinski ---
(In reply to Tejas Belagod from comment #7)
> I tried this, but it still doesn't seem to fold for aarch64.
>
> So, here is the DOM trace for aarch64:
>
> Optimizing statement a = *.LC0;
Why do we get LC0 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #7 from Tejas Belagod ---
I tried this, but it still doesn't seem to fold for aarch64.
So, here is the DOM trace for aarch64:
Optimizing statement a = *.LC0;
LKUP STMT a = *.LC0 with .MEM_3(D)
LKUP STMT *.LC0 = a with .MEM_3(D)
Opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #5 from Tejas Belagod ---
>
> Index: passes.def
> ===
> --- passes.def (revision 217035)
> +++ passes.def (working copy)
> @@ -255,7 +255,7 @@
>NEXT_PASS (pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Miles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #3 from Tejas Belagod ---
When I try 5.0 with -fno-tree-vectorize, I get:
;; basic block 2, loop depth 0
;;pred: ENTRY
# .MEM_4 = VDEF <.MEM_3(D)>
aD.2496 = *.LC0D.2503;
# VUSE <.MEM_4>
_10 = aD.2496[0];
# VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #2 from Tejas Belagod ---
foo.c.optimized:
5.0:
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
# .MEM_4 = VDEF <.MEM_3(D)>
aD.1380 = *.LC0D.1387;
# VUSE <.MEM_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #1 from Richard Biener ---
How does it look before RTL expansion with 4.9 vs. 5.0?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
Tejas Belagod changed:
What|Removed |Added
Target||aarch64
Status|UNCONFIRMED
24 matches
Mail list logo
