linux-kernel - Re: [PATCH] TRACING: Fix a copmile warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4E2F270C.7020100@redhat.com>
Date:	Tue, 26 Jul 2011 14:43:56 -0600
From:	Jeff Law <law@...hat.com>
To:	Arnaud Lacombe <lacombar@...il.com>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	Ian Lance Taylor <iant@...gle.com>, gcc-help@....gnu.org,
	stufever@...il.com, linux-kernel@...r.kernel.org,
	Wang Shaoyan <wangshaoyan.pt@...bao.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] TRACING: Fix a copmile warning

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/25/11 19:19, Arnaud Lacombe wrote:
> Hi,
> 
> On Mon, Jul 25, 2011 at 9:12 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
>> On Mon, 2011-07-25 at 21:08 -0400, Arnaud Lacombe wrote:
>>> Hi,
>>>
>>
>>> but the code generated seem to test %esi (`b', potentially
>>> uninitialized) before %ebx (`a'). Am I still missing something ?
>>
>> But it tests 'a' again afterward. If 'a' is 0, it doesn't matter what
>> 'b' was. So the uninitialized test is a wash. No harm done, except for
>> some wasted CPU cycles.
>>
> I see, even if `b' is junk, the final logic does not change.
Right.
Here's the .optimized dump I get for -Os:



<bb 2>:
  a_2 = e ();
  if (a_2 != 0B)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  b_4 = f ();

<bb 4>:
  # b_1 = PHI <b_3(D)(2), b_4(3)>
  D.2708_5 = a_2 != 0B;
  D.2709_6 = b_1 != 0B;
  D.2710_7 = D.2709_6 & D.2708_5;
  if (D.2710_7 != 0)
    goto <bb 5>;
  else
    goto <bb 6>;

<bb 5>:
  g (); [tail call]

<bb 6>:
  return;

If we duplicate bb4 and isolate the paths leading out of bb2 we'd get
something like this:

<bb 2>:
  a_2 = e ();
  if (a_2 != 0B)
    goto <bb 3>;
  else
    goto <bb 7>;

<bb 3>:
  b_4 = f ();

<bb 4>:
  # b_1 = PHI  b_4(3)>
  D.2708_5 = a_2 != 0B;
  D.2709_6 = b_1 != 0B;
  D.2710_7 = D.2709_6 & D.2708_5;
  if (D.2710_7 != 0)
    goto <bb 5>;
  else
    goto <bb 6>;

<bb 5>:
  g (); [tail call]

<bb 6>:
  return;

<bb 7>:
  # b_1 = PHI <b_3(D)(2))>
  D.2708_5 = a_2 != 0B;
  D.2709_6 = b_1 != 0B;
  D.2710_7 = D.2709_6 & D.2708_5;
  if (D.2710_7 != 0)
    goto <bb 5>;
  else
    goto <bb 6>;


[I'm not going to fix all the SSA_NAMEs, I'm just showing roughly what
can be done with this code... ]

Then we can propagate the fact that a_2 == 0 into bb7 and a2 != 0 into
bb4.  That in turn allows bb7 to collapse into "goto bb6" and bb4
simplifies into if (b4 != 0) goto bb5 else goto bb6.  CFG
simplifications then eliminate the jump and combine bb3 & bb4 resulting in:




<bb 2>:
  a_2 = e ();
  if (a_2 != 0B)
    goto <bb 3>;
  else
    goto <bb 6>;

<bb 3>:
  b_4 = f ();
  if (b_4 != 0)
    goto <bb 5>;
  else
    goto <bb 6>;

<bb 5>:
  g (); [tail call]

<bb 6>:
  return;


Which just happens to be the code we get from -O2.  Unfortunately we
don't in general know when block duplication of this nature is going to
allow enough simplification to justify the possible code expansion.
Thus block duplication of this nature is severely limited when compiling
with -Os.

Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOLycMAAoJEBRtltQi2kC7wbQH/RO2vAAEoHFuJKapNewMcL39
Fm404+DxN1BWwt6HT1BQYfH9tpZCepAJzDVcVsYWFlDOabLUKos9Sju/O8qkSkWK
gYdZ/XbhntB+vNaEQEXz+DdDnbX1OCPCTwM5bjtJ6Gwkjk5W7fa+GHFo694UZ0fH
fgKpAuTVFaCGj94whReGmsNDe0CbpBYS9+Erx4uUsasfkyy5sLDwGaM7gEtg0VS/
ZMz2bP1RDslk3WVkitllO9msq7i70dlR8qw8UgaUSyyvpNrw0HcRxXoI9ZB82mm4
QCtrRD5S92gxdzTtJ0Jg6co+tS2NadDv4D4f9Fn1Ox2oE/oYWvKBvLgkI8Up2pk=
=5lTt
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/