http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #26 from Alex Gaynor 2011-11-05
20:08:08 UTC ---
Thank you very much for fixing this!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #25 from Jakub Jelinek 2011-11-05
19:58:41 UTC ---
Author: jakub
Date: Sat Nov 5 19:58:37 2011
New Revision: 181014
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181014
Log:
PR tree-optimization/50693
* tree-cfg.c (g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #23 from Alexandre Oliva 2011-10-25
04:48:24 UTC ---
Yup. We don't even need a new debug stmt type, methinks. Say, emit the debug
stmt with the LABEL_DECL, decay that to a debug stmt in cfgexpand, and turn
that into a NOTE_INSN_DELE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #22 from Richard Guenther 2011-10-12
15:19:54 UTC ---
Yeah, maybe we can just throw them away with -O3. Or decay them (on BB
merging) to
# DEBUG user_label:
that exposes the label to more code motion issues, so its location would b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #21 from Alex Gaynor 2011-10-11
16:02:56 UTC ---
Given the concern for preserving labels for debugging, perhaps allowing the
merging of basic blocks that eliminate labels could be conditional on either a
new function attribute or comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #20 from Jakub Jelinek 2011-10-11
14:50:51 UTC ---
(In reply to comment #17)
> LLVM appears to be able to recognize memset of any value, not just zero. And
> apparently performs control flow simplification before attempting to recogn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #19 from Richard Guenther 2011-10-11
14:45:22 UTC ---
(In reply to comment #17)
> LLVM appears to be able to recognize memset of any value, not just zero. And
> apparently performs control flow simplification before attempting to rec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
Richard Guenther changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #17 from David Edelsohn 2011-10-11
14:40:09 UTC ---
LLVM appears to be able to recognize memset of any value, not just zero. And
apparently performs control flow simplification before attempting to recognize
the idiom, so it can expo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #16 from Richard Guenther 2011-10-11
14:35:17 UTC ---
(In reply to comment #14)
> A memcmp too?!? (see also the discussion part of libstdc++/50661).
No, only memset with zero.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #15 from Richard Guenther 2011-10-11
14:34:47 UTC ---
Note that it doesn't handle memset though, and the convoluted loop wouldn't be
easy to detect either.
size_t i = 0;
bool loop_cond = i < n;
while (loop_cond) {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #14 from Paolo Carlini 2011-10-11
14:14:24 UTC ---
A memcmp too?!? (see also the discussion part of libstdc++/50661).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #13 from Richard Guenther 2011-10-11
14:13:11 UTC ---
(In reply to comment #12)
> Because the vectorizer analysis occurs fairly early, I guess there is not a
> lot
> of opportunity to clean up the control flow.
>
> Should GCC have a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #12 from David Edelsohn 2011-10-11
14:06:34 UTC ---
Because the vectorizer analysis occurs fairly early, I guess there is not a lot
of opportunity to clean up the control flow.
Should GCC have a memset peephole pass like LLVM?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
Ira Rosen changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #11 from I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #10 from David Edelsohn 2011-10-11
01:35:20 UTC ---
Sorry, I was looking at the loop1 and loop2 functions, not the code inlined
into the benchmark for main.
LLVM generates:
movq%r12, %rdi
movl$99, %esi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #9 from Andrew Pinski 2011-10-11
01:24:00 UTC ---
The vectorization is not being done for the second version of the loop with the
goto. I have not looked into the cause of it though. Note -fno-tree-vectorize
shows that the loop is s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
20 matches
Mail list logo
