From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: rms@gnu.org Cc: craig@jcb-sc.com Subject: Re: type based aliasing again Date: Sat, 11 Sep 1999 03:51:00 -0000 Message-id: <19990911104435.13384.qmail@deer> References: <199909100708.AAA00030@atrus.synopsys.com> <19990910152622.9143.qmail@deer> <199909110725.DAA03149@psilocin.gnu.org> X-SW-Source: 1999-09/msg00437.html >I say we should keep user code found in real programs working, as long >as that is easy to do. Sometimes it is necessary or important to >break code people use, and then it's worth doing so. But when we have >an easy and painless way to keep certain code working, then breaking >it is not necessary or important, so we shouldn't. I don't really disagree with this. The "easy to do" part is important. One thing I notice about, e.g., Tim Prince's occasional posts about g77 vis-a-vis commercial compilers is that, while it sometimes suffers in a performance comparison, it tends to more often choose code paths (implementation alternatives might be a better terminology) consistent with how the code actually looks. I haven't investigated any of his examples that I can think of, so perhaps one has to do with the other. But if it's easy for the GCC middle/back ends to generate the "natural" implementation, based on the input code stream (and assuming the front end doesn't obscure that stream), in the absence of a clear preference based on, for example, optimization, then IMO it's better for GCC to default to that approach than otherwise. That's because while, indeed, such a choice might (as Marc correctly points out) generate the impression that user code works better than it otherwise would, or will, on future architectures, better compilers, *different* compilers, and so on, given the width and breadth of code compiled by GCC and the programmers who write (and have written and will write) such code, a compiler that tends to implement code the "natural" way when there's no clear choice as to which is best will be more apt to help the *industry* deploy more immediately stable products overall. I want to emphasize that "easy to do", in RMS's terms, means to me that the compiler should *itself* never make this assessment. It should be made only by compiler writers, based on a cursory examination. So I'm not suggesting anyone change GCC to implement "foo(i++,i++,i++);" to evaluate the arguments left-to-right instead of right-to-left if *it* can reckon there'd be no substantial performance penalty for doing so. But I'm suggesting perhaps it *should* so implement it if there's no *general* likelihood of a performance penalty for left-to-right order vs. right-to-left order. (If it's just a matter of a tm.h macro definition or some such thing.) It is so difficult to explain this so users don't misunderstand this as some sort of promise for a long-term accommodation of certain sorts of broken code, that I don't suggest we do it in anything that appears to be user documentation. Internal documentation, or recommendations for how GCC (or GNU) programmers should code things? Fine -- users who are interested in implementation internals should read that. Let them therefore recognize that one of the benefits of free-software products is that their development process is necessarily more open, so that they aren't likely to have similar access to internal info on proprietary software. (If we make such statements in *user* docs, we encourage proprietary-software makers to make similar *promises*, which might, in the absence of internal docs, actually lead some users to believe them.) That being said, I've long wanted an option that I'll call, for the moment, `-fconfound-me', that directs code generators, interpreters, and so on to, wherever they are prepared to (and allowed by the relevant specifications), do things in an "unexpected", rather than "natural", way, so I could evaluate whether my code stands up to such "abuse". That option might not reverse order of argument evaluation on an architecture where one order will be generally more optimal than another. But it would cause the compiler to choose, where choices of "naturalness" have been consciously made vis-a-vis the option, the "unnatural" path. (In the g77 front end, this would do simple things like reverse the order of operands in "A+B" as it presents them to the back end. Of course, if the back end also supports the option and reverses them.... ;-) I'm not asking for GCC to implement this option, even as a stub for whoever might want to start testing it within their middle/back-end code in the future, though. That's because, having long *wanted* such an option, I've long envisioned what a compiler architected to support this option (and others I'd like) would look like internally. It's not exactly trivial, and the complexity it would add to GCC in particular, over the long haul, could be one of the many straws in the camel's back making it unmaintainable. My awareness of the possible desirability of such an option might also explain to some why I'm so hesitant about us doing anything that might make *users* of GCC think we will always manage to accommodate their less-than-perfect coding techniques. In particular, once my proposed option existed and started getting used, "clever" programmers might start to reason "well, now you can have the compiler make better choices as to what *is* natural, based on *dynamic* assessment of the various choices and their costs, because that'll help support -fconfound-me too -- it can make more-confounding choices based on recognizing their lack of substantial performance impact on a dynamic basis". (There are lots more things that fall out of this, that are at least as reasonable -- I won't go into them here, but some of them are *way* cool.) It'd be at least as hard *then* to resist that logic as it is *now* to resist the logic of the statement "GCC should choose the more natural implementation unless there's a clear win for choosing some other implementation" (which is *not* what RMS is saying, thankfully). So I view RMS's statement about how GCC should behave, vis-a-vis what users should expect, the way I view "the separation of church and state" vis-a-vis the legislative/executive branches versus the judicial branch of the US government -- the legislative/executive should take up the standard so as to reduce the friction resulting from the judicial stepping a tad out of line, but the latter should *never* use that strict a standard to force the former back into line. (NB I said that's how *I* view that standard vis-a-vis government: I'm not in any way asking others to view it the same way. I might suggest it'd lead to less friction and more freedom if the respective branches of government viewed their responsibilities accordingly, based on a more engineering-like view of "tolerance". But I haven't read the legislative and judicial history of the standard itself, so my analysis is not a "legal" one.) I.e. we should decide for *ourselves* as GCC developers (and of course users can send in patches if they like) to what degree we can and should support "naturalness". As long as we make a good-faith attempt to do so, reasonable, even *slightly* extreme, users will ultimately appreciate our efforts. But when *users* claim GCC didn't choose a "natural" implementation for some construct and thus broke (or, more precisely, exposed breakage in) their code, we should, as developers, make it clear *to users* (even if we might go the extra mile ourselves to help) that it is up to *them* to show that the choice GCC made couldn't have benefited performance in any general circumstance *and* is easy for GCC to choose differently. The default response should be "GCC is generating code in line with the pertinent standards and specifications, which is all you should expect", so that any extra help we give is clearly seen to proceed from that basis. In the end, the caveat "easy to do" carries with it so much more than mere ease of coding, or even ease of decision-making, when *implementing* the compiler. If we in any way make this promise to *users* of GCC, we invite negative feedback in so many potential cases, that the end result could be that *very* little "naturalness" ends up as "easy to do" -- thanks to all the hassles of getting into discussions like this over every little implementation detail. So, if the GCC Steering Committee decided to drop RMS's advice for now, on the basis that GCC wasn't yet close to meeting the *basic* promises of standards conformance and adequate specification of extensions, so all effort needed to be concentrated there and not at low-level implementation details (and discussions arising therefrom), I wouldn't disagree with that either. (Though I think g77 is meeting FORTRAN 77 standards conformance well enough already, and probably the same is true for the C compiler as well...but g++, I don't know. And we're mostly in the same boat here: if the g++ people are still working hard just to conform to a moving-target standard *and* their work requires getting basic conformance in the middle/back end *and* that affects gcc/g77, then it might indeed be wise to not attempt to meet RMS's standard vis-a-vis even gcc and g77 until things "settle down" in the middle/back end.) tq vm, (burley) From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: rms@gnu.org Cc: craig@jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990911104435.13384.qmail@deer> References: <199909100708.AAA00030@atrus.synopsys.com> <19990910152622.9143.qmail@deer> <199909110725.DAA03149@psilocin.gnu.org> X-SW-Source: 1999-09n/msg00437.html Message-ID: <19990930180200.oO2GZofebg9iIWREt54KQ1FNorSe25PFSlJLhw-GAew@z> >I say we should keep user code found in real programs working, as long >as that is easy to do. Sometimes it is necessary or important to >break code people use, and then it's worth doing so. But when we have >an easy and painless way to keep certain code working, then breaking >it is not necessary or important, so we shouldn't. I don't really disagree with this. The "easy to do" part is important. One thing I notice about, e.g., Tim Prince's occasional posts about g77 vis-a-vis commercial compilers is that, while it sometimes suffers in a performance comparison, it tends to more often choose code paths (implementation alternatives might be a better terminology) consistent with how the code actually looks. I haven't investigated any of his examples that I can think of, so perhaps one has to do with the other. But if it's easy for the GCC middle/back ends to generate the "natural" implementation, based on the input code stream (and assuming the front end doesn't obscure that stream), in the absence of a clear preference based on, for example, optimization, then IMO it's better for GCC to default to that approach than otherwise. That's because while, indeed, such a choice might (as Marc correctly points out) generate the impression that user code works better than it otherwise would, or will, on future architectures, better compilers, *different* compilers, and so on, given the width and breadth of code compiled by GCC and the programmers who write (and have written and will write) such code, a compiler that tends to implement code the "natural" way when there's no clear choice as to which is best will be more apt to help the *industry* deploy more immediately stable products overall. I want to emphasize that "easy to do", in RMS's terms, means to me that the compiler should *itself* never make this assessment. It should be made only by compiler writers, based on a cursory examination. So I'm not suggesting anyone change GCC to implement "foo(i++,i++,i++);" to evaluate the arguments left-to-right instead of right-to-left if *it* can reckon there'd be no substantial performance penalty for doing so. But I'm suggesting perhaps it *should* so implement it if there's no *general* likelihood of a performance penalty for left-to-right order vs. right-to-left order. (If it's just a matter of a tm.h macro definition or some such thing.) It is so difficult to explain this so users don't misunderstand this as some sort of promise for a long-term accommodation of certain sorts of broken code, that I don't suggest we do it in anything that appears to be user documentation. Internal documentation, or recommendations for how GCC (or GNU) programmers should code things? Fine -- users who are interested in implementation internals should read that. Let them therefore recognize that one of the benefits of free-software products is that their development process is necessarily more open, so that they aren't likely to have similar access to internal info on proprietary software. (If we make such statements in *user* docs, we encourage proprietary-software makers to make similar *promises*, which might, in the absence of internal docs, actually lead some users to believe them.) That being said, I've long wanted an option that I'll call, for the moment, `-fconfound-me', that directs code generators, interpreters, and so on to, wherever they are prepared to (and allowed by the relevant specifications), do things in an "unexpected", rather than "natural", way, so I could evaluate whether my code stands up to such "abuse". That option might not reverse order of argument evaluation on an architecture where one order will be generally more optimal than another. But it would cause the compiler to choose, where choices of "naturalness" have been consciously made vis-a-vis the option, the "unnatural" path. (In the g77 front end, this would do simple things like reverse the order of operands in "A+B" as it presents them to the back end. Of course, if the back end also supports the option and reverses them.... ;-) I'm not asking for GCC to implement this option, even as a stub for whoever might want to start testing it within their middle/back-end code in the future, though. That's because, having long *wanted* such an option, I've long envisioned what a compiler architected to support this option (and others I'd like) would look like internally. It's not exactly trivial, and the complexity it would add to GCC in particular, over the long haul, could be one of the many straws in the camel's back making it unmaintainable. My awareness of the possible desirability of such an option might also explain to some why I'm so hesitant about us doing anything that might make *users* of GCC think we will always manage to accommodate their less-than-perfect coding techniques. In particular, once my proposed option existed and started getting used, "clever" programmers might start to reason "well, now you can have the compiler make better choices as to what *is* natural, based on *dynamic* assessment of the various choices and their costs, because that'll help support -fconfound-me too -- it can make more-confounding choices based on recognizing their lack of substantial performance impact on a dynamic basis". (There are lots more things that fall out of this, that are at least as reasonable -- I won't go into them here, but some of them are *way* cool.) It'd be at least as hard *then* to resist that logic as it is *now* to resist the logic of the statement "GCC should choose the more natural implementation unless there's a clear win for choosing some other implementation" (which is *not* what RMS is saying, thankfully). So I view RMS's statement about how GCC should behave, vis-a-vis what users should expect, the way I view "the separation of church and state" vis-a-vis the legislative/executive branches versus the judicial branch of the US government -- the legislative/executive should take up the standard so as to reduce the friction resulting from the judicial stepping a tad out of line, but the latter should *never* use that strict a standard to force the former back into line. (NB I said that's how *I* view that standard vis-a-vis government: I'm not in any way asking others to view it the same way. I might suggest it'd lead to less friction and more freedom if the respective branches of government viewed their responsibilities accordingly, based on a more engineering-like view of "tolerance". But I haven't read the legislative and judicial history of the standard itself, so my analysis is not a "legal" one.) I.e. we should decide for *ourselves* as GCC developers (and of course users can send in patches if they like) to what degree we can and should support "naturalness". As long as we make a good-faith attempt to do so, reasonable, even *slightly* extreme, users will ultimately appreciate our efforts. But when *users* claim GCC didn't choose a "natural" implementation for some construct and thus broke (or, more precisely, exposed breakage in) their code, we should, as developers, make it clear *to users* (even if we might go the extra mile ourselves to help) that it is up to *them* to show that the choice GCC made couldn't have benefited performance in any general circumstance *and* is easy for GCC to choose differently. The default response should be "GCC is generating code in line with the pertinent standards and specifications, which is all you should expect", so that any extra help we give is clearly seen to proceed from that basis. In the end, the caveat "easy to do" carries with it so much more than mere ease of coding, or even ease of decision-making, when *implementing* the compiler. If we in any way make this promise to *users* of GCC, we invite negative feedback in so many potential cases, that the end result could be that *very* little "naturalness" ends up as "easy to do" -- thanks to all the hassles of getting into discussions like this over every little implementation detail. So, if the GCC Steering Committee decided to drop RMS's advice for now, on the basis that GCC wasn't yet close to meeting the *basic* promises of standards conformance and adequate specification of extensions, so all effort needed to be concentrated there and not at low-level implementation details (and discussions arising therefrom), I wouldn't disagree with that either. (Though I think g77 is meeting FORTRAN 77 standards conformance well enough already, and probably the same is true for the C compiler as well...but g++, I don't know. And we're mostly in the same boat here: if the g++ people are still working hard just to conform to a moving-target standard *and* their work requires getting basic conformance in the middle/back end *and* that affects gcc/g77, then it might indeed be wise to not attempt to meet RMS's standard vis-a-vis even gcc and g77 until things "settle down" in the middle/back end.) tq vm, (burley)