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:
>>>>
>>>&g
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!
>>>
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, I
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
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
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
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
