https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #20 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #19)
> for the original testcase in comment #0, renaming main to f and changing the
> return type to void, the trunk of GCC can optimize the function to just a
> retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:f5fb9ff2396fd41fdd2e6d35a412e936d2d42f75
commit r14-2852-gf5fb9ff2396fd41fdd2e6d35a412e936d2d42f75
Author: Jan Hubicka
Date: Fri J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #17 from Jan Hubicka ---
I posted the patch. With it we split the loop, but we don't get really big
improvements from that
h@ryzen3:~/gcc/build3/gcc> ./xgcc -B ./ -Ofast c.ii -S -fopt-info 2>&1 | grep
split ; perf stat ./a.out
c.C:15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #16 from Jan Hubicka ---
I am testing the following that makes loop splitting understand when first
iteration is special.
diff --git a/gcc/tree-ssa-loop-split.cc b/gcc/tree-ssa-loop-split.cc
index 70cd0aaefa7..1fd3ee1d1e5 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #13 from Andrew Pinski ---
On the trunk, loop splitting code is there but it is not actually splitting the
loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #11 from Andrew Pinski ---
(In reply to Markus Trippelsdorf from comment #10)
> (In reply to Richard Biener from comment #5)
> > we can't remove the stores because we still can't grok C++ new/delete.
>
> Is there a PR that tracks thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #10 from Markus Trippelsdorf ---
(In reply to Richard Biener from comment #5)
> we can't remove the stores because we still can't grok C++ new/delete.
Is there a PR that tracks this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #9 from Uroš Bizjak ---
(In reply to morandidodo from comment #8)
> Actually, I tried it, but it does not seem to work. Indeed, using
> -mveclibabi=svml -lsvml -I(path-to-intel-lib-dir) does not seem to change
> the call address. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #8 from morandidodo at gmail dot com ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to morandidodo from comment #6)
>
> > However, I just made some tests, and it seems that the performance lost is
> > particularly related t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #7 from Uroš Bizjak ---
(In reply to morandidodo from comment #6)
> However, I just made some tests, and it seems that the performance lost is
> particularly related to std::log. If something else is being used, like
> std::sqrt for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #6 from morandidodo at gmail dot com ---
(In reply to Richard Biener from comment #1)
> First of all you need to make sure to have recent glibc installed to benefit
> from
> the vectorized math routines therein. Otherwise we cannot ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
Richard Biener changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #4 from Markus Trippelsdorf ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Markus Trippelsdorf from comment #2)
> > Clang is pretty impressive using libc++ and -Ofast:
>
> Looks like they can remove all stores from th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #3 from Andrew Pinski ---
(In reply to Markus Trippelsdorf from comment #2)
> Clang is pretty impressive using libc++ and -Ofast:
Looks like they can remove all stores from the loop. Though it does not remove
the empty loop afterwar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRM
20 matches
Mail list logo
