jj@idris.id.dk (Jesper Joergensen [ris]) (01/10/90)
ATTN: Michael Tiemann This message contains the subjects: 1/ Superfluous calls to ___builtin_delete 2/ Question concerning importance of things I'm using: G++ version 1.36.1 under: Ultrix V2.2-1 Worksystem V1.1 on a: DEC VAXstation 2000 1/ Superfluous calls to ___builtin_delete ========================================= I'm still following the recommendations in the manuals to test the influence of some of the selective optimization qualifiers (-fforce-mem etc.), which first of all means that I take at look at the generated code. While doing the latter, I stumbled into a VERY COMMON piece of code surrounding calls to ___builtin_delete, which is directly superfluous on occasions. READ ON ... The codes pseudo C equivalent is: >> if <test-value> { >> push <argument> >> call ___builtin_delete >> } in VAX assembler (with explanations) this looks like: >> tstl <test-value> ; compare operand with zero >> jeql L1855 ; jump if equal (skip delete) >> pushl <argument> ; push on stack >> calls $1,___builtin_delete ; call with stacked arg. list >>L1855: THIS PIECE OF CODE OCCURS HUNDREDS (and I mean HUNDREDS) OF TIMES IN MY PROGRAM WITH THE <test-value> BEING A C O N S T A N T (0 or 1) !?!?!?!?!?!?!?!?!?!? As far as I can see this code is the standard end of a destructor, and checks whether the destroyed object should be actually deleted, which it must not be if it's automatic or part of an array. The requirements for this conditional are clear and obvious if we're talking about a general destructor (which is to be called), but if the destructor is INLINE expanded, as I think is the case here, then one knows the outfall of this test at compile time, which of course makes it redundant at runtime (as can be clearly infered from the code above). Sometimes the code uses a register for <test-value>, which has been zeroed unconditionally earlier (at the start of a destruction loop) and which isn't used for anything else. The standard elimination of constant conditionals explained in the GCC manual, which I believe you have inherited, doesn't catch this construct. I believe it is because that optimization takes place before RTL generation and the above construct is not generated until it has to occur in RTL form, however I'm not sure. There must be another way or am I (or GCC) missing something. THE CONSEQUENCE OF THIS EXTRA CODE is that the caller may become too large for inlining itself, when such a destructor is inline expanded into it. Finally it is also a complete waste having all this unreachable code lying around, since it may very well occur in large numbers (it does in my case). 2/ Question concerning importance of things =========================================== I'm very concerned about bothering other people with matters of low priority, especially someone like you, which must be receiving hundreds of mail messages from god-knows-where every day. I know that BUG reports are always welcome and your manuals say that (some) suggestions are as well, but some of my 'neat little ideas' might not be of a significance which matters in your work. I judge very hard before sending you mail on a specific subject (which isn't a BUG report), but sometimes I am in doubt whether or not my problem is of importance. So is it possible that you could add a note to the replies you send to me and other people, which states your priority of the problems discussed. This will help me save both some of your time as well as some of my own. If you have a general priority list I would very much like to see it. Thanks again for your attention (hope it was important enough &:+) Jesper Jorgensen jj@idris.id.dk Research associate Department of Computer Science Technical University of Denmark DK-2800 Lyngby DENMARK