X-pop3-spooler: POP3MAIL 2.1.0 b 4 980420 -bs- Date: Thu, 17 Sep 1998 09:06:27 -0500 (EST) From: Steven Snyder X-Sender: ssnyder AT indy3 To: pgcc mailing list cc: egcs AT cygnus DOT com Subject: Why does "volatile" improve Pentium code generation? Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1426084764-1462564053-906041187=:11754" Sender: Marc Lehmann Status: RO X-Status: A Content-Length: 4239 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: 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: Content-Description: DQpleHRlcm4gdm9sYXRpbGUgdW5zaWduZWQgc2hvcnQgKiBjb25zdCBteXB0 cjsNCg0KZXh0ZXJuIGlubGluZSB2b2lkIHdydF9ub19vcHQodW5zaWduZWQg Y2hhciByZWcsIHVuc2lnbmVkIGNoYXIgdmFsKQ0Kew0KICAgKiggKHVuc2ln bmVkIHNob3J0ICogY29uc3QpKG15cHRyICsgMHhBOCkgKSA9ICggKHZhbCAq IDB4MTAwKSArIHJlZyApOw0KfQ0KDQpleHRlcm4gaW5saW5lIHZvaWQgd3J0 X3dpdGhfb3B0KHVuc2lnbmVkIGNoYXIgcmVnLCB1bnNpZ25lZCBjaGFyIHZh bCkNCnsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqKG15cHRy ICsgMHhBOCkgPSAoICh2YWwgKiAweDEwMCkgKyByZWcgKTsNCn0NCg0Kdm9p ZCBjYXN0YnVnMSh2b2lkKQ0Kew0KICAgd3J0X25vX29wdCgweDE4LCAweEZG KTsNCiAgIHdydF9ub19vcHQoMHgxNywgMHhFMyk7DQp9DQoNCnZvaWQgY2Fz dGJ1ZzIodm9pZCkNCnsNCiAgIHdydF93aXRoX29wdCgweDE4LCAweEZGKTsN CiAgIHdydF93aXRoX29wdCgweDE3LCAweEUzKTsNCn0NCg0KDQo= --1426084764-1462564053-906041187=:11754--