http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #24 from Paolo Carlini 2011-10-11
19:10:12 UTC ---
:) Sorry about the italian chattering between me and Vincenzo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #23 from pcarlini at gmail dot com 2011-10-11 19:01:02 UTC ---
>
> that never made to mainline
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01560.html
> what about it?
Eh, bisognerebbe ricostruire, ma mi sa che รจ stato proprio nel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #22 from vincenzo Innocente
2011-10-11 16:12:18 UTC ---
in reference to jakub comment #8
actually there was this patch proposing a "ivdep macro" (identical to INTEL's
one!) that never made to mainline
http://gcc.gnu.org/ml/gcc-patche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #20 from paolo at gcc dot gnu.org
2011-10-11 12:39:23 UTC ---
Author: paolo
Date: Tue Oct 11 12:39:18 2011
New Revision: 179801
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179801
Log:
2011-10-11 Emil Wojak
PR c++/50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
CC|bernds at codesourcery dot |
|com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #16 from Andreas Krebbel 2011-10-11
11:41:12 UTC ---
(In reply to comment #15)
> Andreas, can I have your feedback about this? Is it safe or not to compare
> s390
> pointers with memcmp?
On s390 with 31 bit addressing the uppermost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #15 from Paolo Carlini 2011-10-11
11:05:02 UTC ---
Andreas, can I have your feedback about this? Is it safe or not to compare s390
pointers with memcmp?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #14 from vincenzo Innocente
2011-10-08 13:48:22 UTC ---
Thanks for adding me in the loop.
I wonder if we can reuse
-funsafe-loop-optimizations
to force loop vectorization.
I know that INTEL has introduced a specific pragma to force v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #13 from Jakub Jelinek 2011-10-08
13:08:21 UTC ---
So far I've been mostly looking at C loops (e.g. the ones reported by Vincenzo
or derived from those), or, e.g. with
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00135.html for std::v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #12 from Paolo Carlini 2011-10-08
12:57:55 UTC ---
Did you recently check even simpler loops, single range, like std::accumulate?
I'm trying to figure out if we can deal in a light way with the simpler cases,
like provide hints, and t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #11 from Jakub Jelinek 2011-10-08
12:20:34 UTC ---
One possibility would be some fallthru hint to the compiler similar to
__builtin_assume_aligned that would tell the compiler that certain range of
bytes will not trap/fault on reading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
CC||vincenzo.innocente at cern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #8 from Jakub Jelinek 2011-10-08
11:34:51 UTC ---
I guess the problem with autovectorization of loop like:
for (i = 0; i < n; i++)
if (array1[i] != array2[i])
break;
return i == n;
is the control flow in the loop and tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #7 from Paolo Carlini 2011-10-08
11:19:04 UTC ---
I see, in principle 256 bits too at a time, with avx or something, I guess.
That reminds me, i dont's why appropriate command line switches should not
trigger the use of the same instr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #6 from Marc Glisse 2011-10-08
10:59:31 UTC ---
(In reply to comment #5)
> The analogy with copying and traits is enticing, but before reading Marc's
> message, I wondered: for pointers, which kind of improvement are we talking
> abou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #5 from Paolo Carlini 2011-10-08
09:28:10 UTC ---
The analogy with copying and traits is enticing, but before reading Marc's
message, I wondered: for pointers, which kind of improvement are we talking
about? Comparing 64 bits at a tim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #2 from Jakub Jelinek 2011-10-08
07:35:25 UTC ---
Depends if pointer comparison on the architecture is the same as comparing
integer of the same size and if the alignment of the pointer is the same as its
size and all bits are signifi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
24 matches
Mail list logo
