www.delorie.com/archives/browse.cgi   search  
Mail Archives: pgcc/1998/09/17/14:09:11

X-pop3-spooler: POP3MAIL 2.1.0 b 4 980420 -bs-
Date: Thu, 17 Sep 1998 09:06:27 -0500 (EST)
From: Steven Snyder <ssnyder AT indy DOT net>
X-Sender: ssnyder AT indy3
To: pgcc mailing list <beastium-list AT Desk DOT nl>
cc: egcs AT cygnus DOT com
Subject: Why does "volatile" improve Pentium code generation?
Message-ID: <Pine.SUN.3.96.980917090250.11754A-300000@indy3>
MIME-Version: 1.0
Sender: Marc Lehmann <pcg AT goof DOT com>
Status: RO
X-Status: A
Lines: 95

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime AT docserver DOT cac DOT washington DOT edu for more info.

--1426084764-1462564053-906041187=:11754
Content-Type: TEXT/PLAIN; charset=US-ASCII

(I see this code generation under pgcc v1.1a, but am not sure if this is
an issue for pgcc specifically or the underlying egcs compiler.  Please
excuse me if this topic is not pertinent to this mailing list.)

This is an example of how a "volatile" pointer cast strangely causes the
generation of much better Pentium code.  The full files are attached, but
here is a synopses:

  castbug1:
        movl myptr,%eax
        movw $-232,336(%eax)
        movl myptr,%edx
        movw $-7401,336(%edx)

  castbug2:
        movl myptr,%eax
        movl $-232,%edx
        movw %dx,336(%eax)
        movl $-7401,%edx
        movw %dx,336(%eax)

Note that castbug1 has 4 memory accesses, including 2 of the dreaded (for
performance reasons) constant-to-memory move.  In contrast, castbug2 has
only 3 memory accesses, all of which involve registers, not constant
values.  Also, castbug1 has additional AGI stalls due to the pointer being
loaded into the register and being dereferenced in the very next
instruction.

This code generation can be see at any optimization level.  For clarity,
though, I stripped off the stack frame creation/destruction with -O6:

        gcc -c -S -mcpu=i586 -march=i586 -O6 -Wall castbug.c

I found this difference in code generation while investigating why the
pointer code generated for my program was so bad.  I had declared the
pointer to be "const" specifically to avoid having it be reloaded (this
ptr is used *often*), yet it was being reloaded on every use.  It turned
out that I had cast the pointer before using it but had neglected to carry
forward the "volatile" part of the original pointer declaration.  The
compiler silently removed the "volatile" part of the pointer, causing the
code generation shown in castbug1.

(My reason for the "volatile" designation is that the pointer refers to
memory-mapped I/O registers on a video card.  The values in these
registers change dynamically, so I don't want the compiler of optimize
away any references to them.)

What is going on with this optimization?

Thank you.

--1426084764-1462564053-906041187=:11754
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="castbug.s"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine DOT SUN DOT 3 DOT 96 DOT 980917090626 DOT 11754B AT indy3>
Content-Description: 

CS5maWxlCSJjb25zdGJ1Zy5jIg0KCS52ZXJzaW9uCSIwMS4wMSINCmdjYzJf
Y29tcGlsZWQuOg0KLnRleHQNCi5nbG9ibCBjYXN0YnVnMQ0KCS50eXBlCSBj
YXN0YnVnMSxAZnVuY3Rpb24NCmNhc3RidWcxOg0KCW1vdmwgbXlwdHIsJWVh
eA0KCW1vdncgJC0yMzIsMzM2KCVlYXgpDQoJbW92bCBteXB0ciwlZWR4DQoJ
bW92dyAkLTc0MDEsMzM2KCVlZHgpDQoJcmV0DQouTGZlMToNCgkuc2l6ZQkg
Y2FzdGJ1ZzEsLkxmZTEtY2FzdGJ1ZzENCi5nbG9ibCBjYXN0YnVnMg0KCS50
eXBlCSBjYXN0YnVnMixAZnVuY3Rpb24NCmNhc3RidWcyOg0KCW1vdmwgbXlw
dHIsJWVheA0KCW1vdmwgJC0yMzIsJWVkeA0KCW1vdncgJWR4LDMzNiglZWF4
KQ0KCW1vdmwgJC03NDAxLCVlZHgNCgltb3Z3ICVkeCwzMzYoJWVheCkNCgly
ZXQNCi5MZmUyOg0KCS5zaXplCSBjYXN0YnVnMiwuTGZlMi1jYXN0YnVnMg0K
CS5pZGVudAkiR0NDOiAoR05VKSBwZ2NjLTIuOTEuNTcgMTk5ODA5MDEgKGVn
Y3MtMS4xIHJlbGVhc2UpIg0K
--1426084764-1462564053-906041187=:11754
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="castbug.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine DOT SUN DOT 3 DOT 96 DOT 980917090627 DOT 11754C AT indy3>
Content-Description: 

DQpleHRlcm4gdm9sYXRpbGUgdW5zaWduZWQgc2hvcnQgKiBjb25zdCBteXB0
cjsNCg0KZXh0ZXJuIGlubGluZSB2b2lkIHdydF9ub19vcHQodW5zaWduZWQg
Y2hhciByZWcsIHVuc2lnbmVkIGNoYXIgdmFsKQ0Kew0KICAgKiggKHVuc2ln
bmVkIHNob3J0ICogY29uc3QpKG15cHRyICsgMHhBOCkgKSA9ICggKHZhbCAq
IDB4MTAwKSArIHJlZyApOw0KfQ0KDQpleHRlcm4gaW5saW5lIHZvaWQgd3J0
X3dpdGhfb3B0KHVuc2lnbmVkIGNoYXIgcmVnLCB1bnNpZ25lZCBjaGFyIHZh
bCkNCnsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqKG15cHRy
ICsgMHhBOCkgPSAoICh2YWwgKiAweDEwMCkgKyByZWcgKTsNCn0NCg0Kdm9p
ZCBjYXN0YnVnMSh2b2lkKQ0Kew0KICAgd3J0X25vX29wdCgweDE4LCAweEZG
KTsNCiAgIHdydF9ub19vcHQoMHgxNywgMHhFMyk7DQp9DQoNCnZvaWQgY2Fz
dGJ1ZzIodm9pZCkNCnsNCiAgIHdydF93aXRoX29wdCgweDE4LCAweEZGKTsN
CiAgIHdydF93aXRoX29wdCgweDE3LCAweEUzKTsNCn0NCg0KDQo=
--1426084764-1462564053-906041187=:11754--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019