makes things even worse
in some
cases. Anyway, I don't believe it's the best we can do, I'm going to have a
closer look at the scheduler and see what can be done to improve the
situation.
Nikolai
On 09/11/2015 07:21 PM, James Greenhalgh wrote:
On Fri, Sep 11, 2015 at 04:31:37PM +01
Hi!
Recently I got somewhat confused by Cortex-A57 pipeline description in
GCC and
I would be grateful if you could help me understand a few unclear points.
Particularly I am interested in how memory operations (loads/stores) are
scheduled. It seems that according to the cortex-a57.md file, fi
On 07/20/2015 08:11 PM, Jakub Jelinek wrote:
On Mon, Jul 20, 2015 at 07:55:46PM +0300, Nikolai Bozhenov wrote:
On 07/17/2015 08:31 PM, Michael Eager wrote:
On 07/17/2015 03:43 AM, Nikolai Bozhenov wrote:
Consider the following example:
1 extern void bar(int *i1, int *i2, int *i3
On 07/17/2015 08:31 PM, Michael Eager wrote:
On 07/17/2015 03:43 AM, Nikolai Bozhenov wrote:
Consider the following example:
1 extern void bar(int *i1, int *i2, int *i3);
2
3 int __attribute__((noinline)) foo(int i1, int i2) {
4 int a, b, c;
5 a = i1 << i2;
On 07/17/2015 02:16 PM, Kyrill Tkachov wrote:
Have you tried the -Og option?
Well, with -Og operations are not rearranged, so binary code is very
close to the source code and debugging is very straightforward. As for
debug info, it is generally the same: when I try to inspect yet
uninitialize
Hello!
It is certainly true that debugging an optimized code is an inherently
difficult task. Though, I wonder if the compiler could make such
debugging experience slightly less surprising.
Consider the following example:
1 extern void bar(int *i1, int *i2, int *i3);
2
3 int __attri
