Pta_flags enum overflow in i386.c
Hi All! As you may see pta_flags enum in i386.c is almost full. So there is a risk of overflow in quite near future. Comment in source code advises "widen struct pta flags" which is now defined as unsigned. But it looks not optimal. What will be the most proper solution for this problem? Thanks in advance, Igor
Wrong code for i686 target with -O3 -flto
Hi All! Unfortunately now the compiler generates wrong code for i686 target when options -O3 and -flto are used. It started more than a month ago and reflected in PR57602. Such combination of options could be quite important at least from the performance point of view. Since there was almost no reaction on this PR I'd like to ask either to look at it in some observable future or revert the commit which is guilty for the issue. Thanks, Igor
Compilation flags in libgfortran
Hi All! Is there any particular reason that matmul* modules from libgfortran are compiled with -O2 -ftree-vectorize? I see some regressions on Atom processor after r202980 (http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00846.html) Why not just use O3 for those modules? Thanks, Igor
Re: Compilation flags in libgfortran
Thanks a lot for the explanation! I can take care of the benchmarking but only on Intel hardware... Do you think that possble changes according those results would be acceptable? Thanks, Igor On Tue, Oct 15, 2013 at 11:46 PM, Janne Blomqvist wrote: > On Tue, Oct 15, 2013 at 4:58 PM, Igor Zamyatin wrote: >> Hi All! >> >> Is there any particular reason that matmul* modules from libgfortran >> are compiled with -O2 -ftree-vectorize? > > Yes, testing showed that it improved performance compared to the > default options. See the thread starting at > > http://gcc.gnu.org/ml/fortran/2005-11/msg00366.html > > In the almost 8 years (!!) since the patch was merged, I believe the > importance of vectorization for utilizing current processors has only > increased. > > [snip] > >> Why not just use O3 for those modules? > > Back when the change was made, -ftree-vectorize wasn't enabled by -O3. > IIRC I did some tests, and -O3 didn't really improve things beyond > what "-O2 -funroll-loops -ftree-vectorize" already did. That was a > while ago however, so if somebody (*wink*) would care to redo the > benchmarks things might look different with today's GCC on today's > hardware. > > Hope this helps, > > -- > Janne Blomqvist
Re: Compilation flags in libgfortran
Yeah, this is my point exactly. Atom case seems just triggered that fact. On Wed, Oct 16, 2013 at 2:22 PM, Kyrill Tkachov wrote: > On 16/10/13 10:37, pins...@gmail.com wrote: >>> >>> On Oct 15, 2013, at 6:58 AM, Igor Zamyatin wrote: >>> Hi All! >>> >>> Is there any particular reason that matmul* modules from libgfortran >>> are compiled with -O2 -ftree-vectorize? >>> >>> I see some regressions on Atom processor after r202980 >>> (http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00846.html) >>> >>> Why not just use O3 for those modules? >> >> -O3 and -O2 -ftree-vectorize won't give much performance difference. What >> you are seeing is the cost model needs improvement; at least for atom. > > Hi all, > I think http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01908.html introduced > the new "cheap" vectoriser cost model that favors compilation time over > runtime performance and is set as default for -O2. -O3 uses the "dynamic" > model which potentially gives better runtime performance in exchange for > longer compile times (if I understand the new rules correctly). > Therefore, I'd expect -O3 to give a better vector performance than -O2... > > Kyrill > >
Re: Compilation flags in libgfortran
Yeah, I can try to do benchmarking with such optset instead of O3. Thanks, Igor On Thu, Oct 17, 2013 at 2:19 PM, Richard Biener wrote: > On Wed, Oct 16, 2013 at 12:22 PM, Kyrill Tkachov > wrote: >> On 16/10/13 10:37, pins...@gmail.com wrote: >>>> >>>> On Oct 15, 2013, at 6:58 AM, Igor Zamyatin wrote: >>>> Hi All! >>>> >>>> Is there any particular reason that matmul* modules from libgfortran >>>> are compiled with -O2 -ftree-vectorize? >>>> >>>> I see some regressions on Atom processor after r202980 >>>> (http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00846.html) >>>> >>>> Why not just use O3 for those modules? >>> >>> -O3 and -O2 -ftree-vectorize won't give much performance difference. What >>> you are seeing is the cost model needs improvement; at least for atom. >> >> Hi all, >> I think http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01908.html introduced >> the new "cheap" vectoriser cost model that favors compilation time over >> runtime performance and is set as default for -O2. -O3 uses the "dynamic" >> model which potentially gives better runtime performance in exchange for >> longer compile times (if I understand the new rules correctly). >> Therefore, I'd expect -O3 to give a better vector performance than -O2... > > But this suggests to compile with -O2 -ftree-vectorize > -fvect-cost-model=dynamic, not building with -O3. > > Richard. > >> Kyrill >> >>
Tree loop if conversion at O2
Hi All! Is there any particular reason why tree loop if conversion (tree-if-conv.c) isn't enabled by default on O2 (as far as I can see it's true for any platforms)? Thanks, Igor
