|
From: Christian B. <bor...@de...> - 2014-09-25 04:15:02
Attachments:
diffs.txt
|
valgrind revision: 14566 VEX revision: 2959 C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] GDB: GNU gdb (GDB) SUSE (7.5.1-0.7.29) Assembler: GNU assembler (GNU Binutils; SUSE Linux Enterprise 11) 2.23.1 C library: GNU C Library stable release version 2.11.3 (20110527) uname -mrs: Linux 3.0.101-0.35-default s390x Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP3 (s390x) - Kernel %r (%t). Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP3 gcc 4.3.4 on z196 (s390x) ) Started at 2014-09-25 03:45:01 CEST Ended at 2014-09-25 06:14:46 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 661 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) helgrind/tests/pth_cond_destroy_busy (stderr) helgrind/tests/tc20_verifywrap (stderr) --tools=none,memcheck,callgrind,helgrind,cachegrind,drd,massif --reps=3 --vg=../valgrind-new --vg=../valgrind-old -- Running tests in perf ---------------------------------------------- -- bigcode1 -- bigcode1 valgrind-new:0.22s no: 4.3s (19.5x, -----) me: 7.2s (32.8x, -----) ca:25.8s (117.2x, -----) he: 5.3s (24.0x, -----) ca: 9.1s (41.5x, -----) dr: 5.5s (24.9x, -----) ma: 4.9s (22.3x, -----) bigcode1 valgrind-old:0.22s no: 4.3s (19.5x, 0.0%) me: 7.2s (32.9x, -0.3%) ca:25.8s (117.2x, 0.0%) he: 5.3s (23.9x, 0.2%) ca: 9.1s (41.5x, 0.0%) dr: 5.5s (24.9x, 0.0%) ma: 4.9s (22.3x, 0.0%) -- bigcode2 -- bigcode2 valgrind-new:0.24s no: 7.2s (30.1x, -----) me:14.0s (58.5x, -----) ca:38.6s (161.0x, -----) he:10.2s (42.5x, -----) ca:14.2s (59.3x, -----) dr: 9.6s (39.9x, -----) ma: 8.3s (34.7x, -----) bigcode2 valgrind-old:0.24s no: 7.2s (30.1x, 0.0%) me:14.0s (58.5x, 0.0%) ca:38.9s (162.1x, -0.7%) he:10.2s (42.5x, 0.1%) ca:14.2s (59.3x, 0.1%) dr: 9.6s (40.0x, -0.1%) ma: 8.3s (34.7x, 0.0%) -- bz2 -- bz2 valgrind-new:0.70s no: 5.0s ( 7.1x, -----) me:13.1s (18.6x, -----) ca:31.4s (44.9x, -----) he:19.8s (28.3x, -----) ca:34.3s (49.0x, -----) dr:29.9s (42.7x, -----) ma: 4.8s ( 6.8x, -----) bz2 valgrind-old:0.70s no: 5.0s ( 7.1x, -0.2%) me:13.2s (18.8x, -0.8%) ca:31.4s (44.9x, 0.0%) he:19.8s (28.3x, 0.0%) ca:34.3s (49.0x, 0.0%) dr:29.9s (42.7x, -0.0%) ma: 4.8s ( 6.8x, 0.2%) -- fbench -- fbench valgrind-new:0.41s no: 1.6s ( 3.9x, -----) me: 4.5s (10.9x, -----) ca: 9.2s (22.5x, -----) he: 6.4s (15.7x, -----) ca: 7.2s (17.7x, -----) dr: 5.8s (14.1x, -----) ma: 1.7s ( 4.1x, -----) fbench valgrind-old:0.41s no: 1.6s ( 4.0x, -0.6%) me: 4.5s (10.9x, 0.0%) ca: 9.2s (22.5x, 0.1%) he: 6.4s (15.7x, 0.2%) ca: 7.2s (17.7x, 0.0%) dr: 5.8s (14.1x, 0.0%) ma: 1.7s ( 4.1x, -0.0%) -- ffbench -- ffbench valgrind-new:0.21s no: 1.1s ( 5.0x, -----) me: 3.5s (16.6x, -----) ca: 3.0s (14.2x, -----) he:44.4s (211.3x, -----) ca: 9.5s (45.2x, -----) dr: 7.4s (35.2x, -----) ma: 1.0s ( 4.7x, -----) ffbench valgrind-old:0.21s no: 1.1s ( 5.0x, 0.0%) me: 3.4s (16.4x, 1.1%) ca: 3.0s (14.2x, 0.0%) he:44.4s (211.4x, -0.0%) ca: 9.5s (45.1x, 0.1%) dr: 7.4s (35.2x, -0.1%) ma: 1.0s ( 4.6x, 1.0%) -- heap -- heap valgrind-new:0.23s no: 1.9s ( 8.2x, -----) me: 8.9s (38.7x, -----) ca:13.0s (56.4x, -----) he:12.7s (55.4x, -----) ca:11.2s (48.6x, -----) dr: 7.8s (34.0x, -----) ma: 8.0s (34.8x, -----) heap valgrind-old:0.23s no: 1.9s ( 8.3x, -1.1%) me: 8.9s (38.7x, 0.0%) ca:12.9s (56.3x, 0.2%) he:12.9s (55.9x, -0.9%) ca:11.2s (48.6x, -0.1%) dr: 7.9s (34.5x, -1.3%) ma: 7.9s (34.5x, 1.0%) -- heap_pdb4 -- heap_pdb4 valgrind-new:0.22s no: 2.0s ( 9.3x, -----) me:13.0s (59.0x, -----) ca:14.2s (64.3x, -----) he:14.2s (64.6x, -----) ca:12.3s (55.7x, -----) dr: 8.9s (40.3x, -----) ma: 8.1s (37.0x, -----) heap_pdb4 valgrind-old:0.22s no: 2.0s ( 9.3x, 0.0%) me:13.0s (59.0x, 0.1%) ca:14.1s (64.2x, 0.2%) he:14.1s (63.9x, 1.1%) ca:12.3s (55.7x, 0.0%) dr: 8.8s (40.1x, 0.5%) ma: 8.1s (37.0x, 0.0%) -- many-loss-records -- many-loss-records valgrind-new:0.02s no: 0.5s (24.0x, -----) me: 2.3s (117.0x, -----) ca: 1.9s (96.0x, -----) he: 2.4s (118.0x, -----) ca: 1.9s (95.5x, -----) dr: 2.0s (99.5x, -----) ma: 1.7s (84.0x, -----) many-loss-records valgrind-old:0.02s no: 0.5s (24.0x, 0.0%) me: 2.3s (116.5x, 0.4%) ca: 1.9s (96.0x, 0.0%) he: 2.4s (118.0x, 0.0%) ca: 1.9s (95.5x, 0.0%) dr: 2.0s (99.5x, 0.0%) ma: 1.7s (84.0x, -0.0%) -- many-xpts -- many-xpts valgrind-new:0.07s no: 0.6s ( 9.0x, -----) me: 3.4s (48.4x, -----) ca:374.8s (5353.6x, -----) he: 6.7s (95.7x, -----) ca: 2.8s (39.9x, -----) dr: 2.8s (39.6x, -----) ma: 2.6s (37.7x, -----) many-xpts valgrind-old:0.07s no: 0.6s ( 9.0x, 0.0%) me: 3.4s (48.4x, 0.0%) ca:371.9s (5312.4x, 0.8%) he: 6.7s (95.9x, -0.1%) ca: 2.8s (39.9x, 0.0%) dr: 2.8s (39.6x, 0.0%) ma: 2.6s (37.7x, 0.0%) -- sarp -- sarp valgrind-new:0.03s no: 0.6s (20.0x, -----) me: 3.7s (123.0x, -----) ca: 3.1s (104.0x, -----) he:17.1s (569.3x, -----) ca: 2.0s (68.3x, -----) dr: 1.6s (52.7x, -----) ma: 0.5s (18.0x, -----) sarp valgrind-old:0.03s no: 0.6s (20.0x, 0.0%) me: 3.7s (122.7x, 0.3%) ca: 3.1s (104.0x, 0.0%) he:16.9s (564.7x, 0.8%) ca: 2.0s (68.3x, 0.0%) dr: 1.6s (53.0x, -0.6%) ma: 0.5s (18.0x, 0.0%) -- tinycc -- tinycc valgrind-new:0.22s no: 2.8s (12.5x, -----) me:14.7s (67.0x, -----) ca:29.7s (135.1x, -----) he:27.8s (126.5x, -----) ca:21.1s (96.1x, -----) dr:20.7s (94.1x, -----) ma: 4.1s (18.7x, -----) tinycc valgrind-old:0.22s no: 2.8s (12.5x, -0.4%) me:14.7s (67.0x, 0.0%) ca:29.8s (135.2x, -0.1%) he:27.8s (126.2x, 0.2%) ca:21.1s (96.1x, 0.0%) dr:20.7s (94.1x, 0.0%) ma: 4.1s (18.7x, -0.2%) -- Finished tests in perf ---------------------------------------------- == 11 programs, 154 timings ================= real 111m31.635s user 110m54.588s sys 0m28.802s |
|
From: Christian B. <bor...@de...> - 2014-09-25 07:34:29
|
On 09/25/2014 06:14 AM, Christian Borntraeger wrote: > valgrind revision: 14566 > VEX revision: 2959 > C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] > GDB: GNU gdb (GDB) SUSE (7.5.1-0.7.29) > Assembler: GNU assembler (GNU Binutils; SUSE Linux Enterprise 11) 2.23.1 > C library: GNU C Library stable release version 2.11.3 (20110527) > uname -mrs: Linux 3.0.101-0.35-default s390x > Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP3 (s390x) - Kernel %r (%t). > > Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP3 gcc 4.3.4 on z196 (s390x) ) > Started at 2014-09-25 03:45:01 CEST > Ended at 2014-09-25 06:14:46 CEST > Results unchanged from 24 hours ago > > Checking out valgrind source tree ... done > Configuring valgrind ... done > Building valgrind ... done > Running regression tests ... failed > > Regression test results follow > > == 661 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == > memcheck/tests/origin5-bz2 (stderr) > helgrind/tests/pth_cond_destroy_busy (stderr) > helgrind/tests/tc20_verifywrap (stderr) > > --tools=none,memcheck,callgrind,helgrind,cachegrind,drd,massif --reps=3 --vg=../valgrind-new --vg=../valgrind-old [....] > many-xpts valgrind-new:0.07s no: 0.6s ( 9.0x, -----) [...] ca:374.8s (5353.6x, -----) [...] > many-xpts valgrind-old:0.07s no: 0.6s ( 9.0x, 0.0%) [...] ca:371.9s (5312.4x, 0.8%) [...] This testcase is really weird. All other tests run fine within seconds, but this takes several minutes. When running the same test in the nightly folder it finishes after 3-4 seconds. No idea what is happening here right now. Any guesses? Christian |
|
From: Christian B. <bor...@de...> - 2014-10-08 15:22:48
|
Am 25.09.2014 09:34, schrieb Christian Borntraeger:
> On 09/25/2014 06:14 AM, Christian Borntraeger wrote:
>> valgrind revision: 14566
>> VEX revision: 2959
>> C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]
>> GDB: GNU gdb (GDB) SUSE (7.5.1-0.7.29)
>> Assembler: GNU assembler (GNU Binutils; SUSE Linux Enterprise 11) 2.23.1
>> C library: GNU C Library stable release version 2.11.3 (20110527)
>> uname -mrs: Linux 3.0.101-0.35-default s390x
>> Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP3 (s390x) - Kernel %r (%t).
>>
>> Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP3 gcc 4.3.4 on z196 (s390x) )
>> Started at 2014-09-25 03:45:01 CEST
>> Ended at 2014-09-25 06:14:46 CEST
>> Results unchanged from 24 hours ago
>>
>> Checking out valgrind source tree ... done
>> Configuring valgrind ... done
>> Building valgrind ... done
>> Running regression tests ... failed
>>
>> Regression test results follow
>>
>> == 661 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
>> memcheck/tests/origin5-bz2 (stderr)
>> helgrind/tests/pth_cond_destroy_busy (stderr)
>> helgrind/tests/tc20_verifywrap (stderr)
>>
>> --tools=none,memcheck,callgrind,helgrind,cachegrind,drd,massif --reps=3 --vg=../valgrind-new --vg=../valgrind-old
> [....]
>> many-xpts valgrind-new:0.07s no: 0.6s ( 9.0x, -----) [...] ca:374.8s (5353.6x, -----) [...]
>> many-xpts valgrind-old:0.07s no: 0.6s ( 9.0x, 0.0%) [...] ca:371.9s (5312.4x, 0.8%) [...]
>
> This testcase is really weird. All other tests run fine within seconds, but this takes several minutes. When running the same test in the nightly folder it finishes after 3-4 seconds. No idea what is happening here right now.
>
> Any guesses?
I can now reproduce this manually. The code spends huge amount of times in
void CLG_(setup_bbcc)(BB* bb) (callgrind/bbcc.c)
in this while loop:
while(1) {
if (top_ce->ret_addr == bb_addr(bb)) break;
if (csp_up>0) {
csp_up--;
top_ce = &(CLG_(current_call_stack).entry[csp_up]);
if (top_ce->sp == sp) {
popcount_on_return++;
continue;
}
}
popcount_on_return = 0;
break;
}
The reason is that the value of csp is increasing during that testcase to insanely high values.
I have to admit, that I dont fully understand that code, so any ideas are welcome.
|
|
From: Josef W. <Jos...@gm...> - 2014-10-08 18:26:46
|
Am 08.10.2014 um 13:29 schrieb Christian Borntraeger:
>>> many-xpts valgrind-new:0.07s no: 0.6s ( 9.0x, -----) [...] ca:374.8s (5353.6x, -----) [...]
>>> many-xpts valgrind-old:0.07s no: 0.6s ( 9.0x, 0.0%) [...] ca:371.9s (5312.4x, 0.8%) [...]
>
> I can now reproduce this manually.
Cool.
The code spends huge amount of times in
> void CLG_(setup_bbcc)(BB* bb) (callgrind/bbcc.c)
>
> in this while loop:
>
> while(1) {
> if (top_ce->ret_addr == bb_addr(bb)) break;
> if (csp_up>0) {
> csp_up--;
> top_ce = &(CLG_(current_call_stack).entry[csp_up]);
> if (top_ce->sp == sp) {
> popcount_on_return++;
> continue;
> }
> }
> popcount_on_return = 0;
> break;
> }
setup_bbcc is called from instrumented code at entry of every basic block.
Callgrind maintains a shadow stack, and this code is part of
synchronizing the shadow stack
with the real stack. It should be executed for a basic block that is
coming after
a guest return instruction was executed.
This may need to pop multiple entries of the shadow stack as Callgrind
tries to interpret
tail recursion optimization (jumps to the beginning of a function) as
calls to that
function, resulting in new entries on the shadow stack (with equal sp)
which all need to be
popped when returning.
Hm. Looking at many-xpts.c, I see that the compiler may do tail
recursion optimization,
but stack frames should not have depths larger than 18 (?).
Can you send me the a callgrind.out result of a Callgrind run of
many-xpts on s390?
> The reason is that the value of csp is increasing during that testcase to insanely high values.
The reason for such high csp values is not really clear to me...
Josef
>
> I have to admit, that I dont fully understand that code, so any ideas are welcome.
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: Florian K. <fl...@ei...> - 2014-10-08 18:31:31
|
On 08.10.2014 13:29, Christian Borntraeger wrote:
>
> I can now reproduce this manually. The code spends huge amount of times in
> void CLG_(setup_bbcc)(BB* bb) (callgrind/bbcc.c)
>
> in this while loop:
>
> while(1) {
> if (top_ce->ret_addr == bb_addr(bb)) break;
> if (csp_up>0) {
> csp_up--;
> top_ce = &(CLG_(current_call_stack).entry[csp_up]);
> if (top_ce->sp == sp) {
> popcount_on_return++;
> continue;
> }
> }
> popcount_on_return = 0;
> break;
> }
>
> The reason is that the value of csp is increasing during that testcase to insanely high values.
?? What is increasing?
>
> I have to admit, that I dont fully understand that code, so any ideas are welcome.
Perhaps this has to do with how we classify function returns.
Any BCR with r1 == 15 will be taken as a return. But that is not
necessarily true (just very often). And a BCR with r1 != 15 is not
considered a return...
Florian
|
|
From: Josef W. <Jos...@gm...> - 2014-10-08 18:44:37
|
Am 08.10.2014 um 20:31 schrieb Florian Krohm: > ... > Perhaps this has to do with how we classify function returns. > Any BCR with r1 == 15 will be taken as a return. But that is not > necessarily true (just very often). And a BCR with r1 != 15 is not > considered a return... Maybe the cited part of code is just executed much more often than on other architectures, because of this classification? I still do not get the large csp values. Josef > > Florian > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Christian B. <bor...@de...> - 2014-10-09 07:53:07
|
Am 08.10.2014 20:31, schrieb Florian Krohm:
> On 08.10.2014 13:29, Christian Borntraeger wrote:
>
>>
>> I can now reproduce this manually. The code spends huge amount of times in
>> void CLG_(setup_bbcc)(BB* bb) (callgrind/bbcc.c)
>>
>> in this while loop:
>>
>> while(1) {
>> if (top_ce->ret_addr == bb_addr(bb)) break;
>> if (csp_up>0) {
>> csp_up--;
>> top_ce = &(CLG_(current_call_stack).entry[csp_up]);
>> if (top_ce->sp == sp) {
>> popcount_on_return++;
>> continue;
>> }
>> }
>> popcount_on_return = 0;
>> break;
>> }
>>
>> The reason is that the value of csp is increasing during that testcase to insanely high values.
>
> ?? What is increasing?
I did a VG_(printf) on csp.
csp = CLG_(current_call_stack).sp;
--> here
/* A return not matching the top call in our callstack is a jump */
if ( (jmpkind == jk_Return) && (csp >0)) {
Int csp_up = csp-1;
it starts sanely moving between 1 and twenty-something for some seconds
and the it goes up (stopped at 23000).
>
>>
>> I have to admit, that I dont fully understand that code, so any ideas are welcome.
>
> Perhaps this has to do with how we classify function returns.
> Any BCR with r1 == 15 will be taken as a return. But that is not
> necessarily true (just very often). And a BCR with r1 != 15 is not
> considered a return...
>
> Florian
>
|
|
From: Christian B. <bor...@de...> - 2014-10-09 18:00:22
|
Am 09.10.2014 16:19, schrieb Josef Weidendorfer:
> Am 09.10.2014 um 10:33 schrieb Christian Borntraeger:
>> Am 08.10.2014 20:26, schrieb Josef Weidendorfer:
>>> Am 08.10.2014 um 13:29 schrieb Christian Borntraeger:
>>>>>> many-xpts valgrind-new:0.07s no: 0.6s ( 9.0x, -----) [...] ca:374.8s (5353.6x, -----) [...]
>>>>>> many-xpts valgrind-old:0.07s no: 0.6s ( 9.0x, 0.0%) [...] ca:371.9s (5312.4x, 0.8%) [...]
>>>>
>>> Can you send me the a callgrind.out result of a Callgrind run of
>>> many-xpts on s390?
>>
>>
>> see attachement.
>
> If I run callgrind on many-xpts here on my laptop, it just calls a1 from a0.
> In your file, there are recursive calls of a0 to a0 with huge call cost.
>
> How does the disassembled code for a0 look like?
>
> Josef
Its pretty straightforward:
stmg save register to memory (r15 is stack)
lmg loads them back
tm?? is test under mask (testing for bits)
j* are jumps
brasl is branch and save long. here r14 is filled with the next instruction address (r14 is return register)
0000000080000938 <a1>:
80000938: eb ef f0 70 00 24 stmg %r14,%r15,112(%r15)
8000093e: a7 fb ff 60 aghi %r15,-160
80000942: a7 21 00 02 tmll %r2,2
80000946: a7 84 00 07 je 80000954 <a1+0x1c>
8000094a: c0 e5 ff ff ff e1 brasl %r14,8000090c <a2>
80000950: a7 f4 00 05 j 8000095a <a1+0x22>
80000954: c0 e5 ff ff ff dc brasl %r14,8000090c <a2>
8000095a: eb ef f1 10 00 04 lmg %r14,%r15,272(%r15)
80000960: 07 fe br %r14
80000962: 07 07 nopr %r7
0000000080000964 <a0>:
80000964: eb ef f0 70 00 24 stmg %r14,%r15,112(%r15)
8000096a: a7 fb ff 60 aghi %r15,-160
8000096e: a7 21 00 01 tmll %r2,1
80000972: a7 84 00 07 je 80000980 <a0+0x1c>
80000976: c0 e5 ff ff ff e1 brasl %r14,80000938 <a1>
8000097c: a7 f4 00 05 j 80000986 <a0+0x22>
80000980: c0 e5 ff ff ff dc brasl %r14,80000938 <a1>
80000986: eb ef f1 10 00 04 lmg %r14,%r15,272(%r15)
8000098c: 07 fe br %r14
8000098e: 07 07 nopr %r7
0000000080000990 <main>:
80000990: eb bf f0 58 00 24 stmg %r11,%r15,88(%r15)
80000996: c0 d0 00 00 00 c1 larl %r13,80000b18 <_IO_stdin_used+0x18>
8000099c: a7 fb ff 60 aghi %r15,-160
800009a0: a7 b8 00 00 lhi %r11,0
800009a4: a5 ce 00 04 llilh %r12,4
800009a8: b9 14 00 2b lgfr %r2,%r11
800009ac: c0 e5 ff ff ff dc brasl %r14,80000964 <a0>
800009b2: a7 ba 00 01 ahi %r11,1
800009b6: a7 c6 ff f9 brct %r12,800009a8 <main+0x18>
800009ba: a7 b8 00 00 lhi %r11,0
800009be: 58 c0 d0 00 l %r12,0(%r13)
800009c2: a7 29 00 ea lghi %r2,234
800009c6: c0 e5 ff ff ff b9 brasl %r14,80000938 <a1>
800009cc: c0 e5 ff ff fd 88 brasl %r14,800004dc <free@plt>
800009d2: a7 29 00 6f lghi %r2,111
800009d6: c0 e5 ff ff ff 9b brasl %r14,8000090c <a2>
800009dc: c0 e5 ff ff fd 80 brasl %r14,800004dc <free@plt>
800009e2: a7 ba 00 01 ahi %r11,1
800009e6: a7 c6 ff ee brct %r12,800009c2 <main+0x32>
800009ea: a7 29 00 00 lghi %r2,0
800009ee: e3 40 f1 10 00 04 lg %r4,272(%r15)
800009f4: eb bf f0 f8 00 04 lmg %r11,%r15,248(%r15)
800009fa: 07 f4 br %r4
Let me know if you need the VEX tracing.
|
|
From: Josef W. <Jos...@gm...> - 2014-10-11 10:03:15
|
Am 09.10.2014 um 20:00 schrieb Christian Borntraeger: > Its pretty straightforward: > ... Indeed, looks pretty simple. > Let me know if you need the VEX tracing. That would be interesting, yes. Can you also send me the callgrind output with "--dump-instr=yes"? Thanks, Josef > > |