* egcs-1.1 release schedule @ 1998-06-18 1:32 Jeffrey A Law 1998-06-19 9:02 ` Gerald Pfeifer ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-18 1:32 UTC (permalink / raw) To: egcs egcs-1.1 The egcs project is rapidly approaching its second major release (egcs-1.1). This page is meant to provide information about the current schedule for egcs-1.1, the testing/release criteria for egcs-1.1, new features to be found in egcs-1.1, etc. The tenative schedule for the egcs-1.1 release is: * July 3, 1998. Feature freeze date. All new features, optimizations, etc need to be submitted by this date. It is very likely we will not be able to integrate all the submissions, but we want to have all of them available for evaluation by this date. It is also possible some patches which have been submitted and are accepted for egcs-1.1 will not have been installed by this date due to EOQ committments for many of the Cygnus volunteers. After July 3, 1998, only bugfix submissions will be considered for the egcs-1.1 release. By July 3, 1998, we also want to have a testing plan and release criteria in place. * July 11, 1998. Branch Creation & Testing. We will create the egcs-1.1 branch on this date and snapshots will occur from the egcs-1.1 branch instead of the mainline sources. By this date we'd like to have all the new features, optimizations, etc slated for the egcs-1.1 release installed in the source tree. We also expect wide scale, focused testing to start on July 11th. * July 31, 1998. Critial Bug Freeze Date. If at all possible we would like to see the release sources freeze except for critical bug fixes by July 31st. This may be overly optimistic, but it's important to have a goal to shoot for. I would like to release as soon as possible in early August. Note that we have the ability to install changes into the mainline sources during this process. However, I personally will be focusing more and more on egcs-1.1 specific issues. It is highly likely we will have some minor releases based on egcs-1.1; we will cross that bridge when the time comes. I also want to do a post-release review of the proposed schedule vs the actual schedule used for egcs-1.1 so that we can improve the process in the future. This message (and future updates) is available on http://www.cygnus.com/egcs/egcs-1.1.html ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-18 1:32 egcs-1.1 release schedule Jeffrey A Law @ 1998-06-19 9:02 ` Gerald Pfeifer 1998-06-19 23:47 ` Jeffrey A Law 1998-06-19 11:57 ` Dave Love 1998-06-20 6:41 ` egcs-1.1 release schedule Gabriel Dos Reis 2 siblings, 1 reply; 47+ messages in thread From: Gerald Pfeifer @ 1998-06-19 9:02 UTC (permalink / raw) To: Jeffrey A Law; +Cc: egcs On Wed, 17 Jun 1998, Jeffrey A Law wrote: > This page is meant to provide information about the current schedule > for egcs-1.1, the testing/release criteria for egcs-1.1, new features > to be found in egcs-1.1, etc. Jeff, I tripped over that new page before receiving your mail announcement and -- while for most of us on the mailing lists that is quite immediate -- I guess the "I" is quite confusing for those not closely following the project. (Specifically, there is no mention on the page who that "I" really is.) Perhaps you could an <ADDRESS> at the end of the page or replace the "I" by "We"? Hope this helps, Gerald -- Gerald Pfeifer (Jerry) Vienna University of Technology pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-19 9:02 ` Gerald Pfeifer @ 1998-06-19 23:47 ` Jeffrey A Law 0 siblings, 0 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-19 23:47 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: egcs In message <Pine.GSO.3.96.980619151159.28850B-100000@markab.dbai.tuwien.ac.atyou write: > On Wed, 17 Jun 1998, Jeffrey A Law wrote: > I tripped over that new page before receiving your mail announcement and > -- while for most of us on the mailing lists that is quite immediate -- > I guess the "I" is quite confusing for those not closely following the > project. Good point. I have an overly informal writing style. I tried to clean up the worst of the problems. Further suggestions/patches are certainly welcome :-) jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-18 1:32 egcs-1.1 release schedule Jeffrey A Law 1998-06-19 9:02 ` Gerald Pfeifer @ 1998-06-19 11:57 ` Dave Love 1998-06-21 21:43 ` Craig Burley 1998-06-21 23:07 ` Jeffrey A Law 1998-06-20 6:41 ` egcs-1.1 release schedule Gabriel Dos Reis 2 siblings, 2 replies; 47+ messages in thread From: Dave Love @ 1998-06-19 11:57 UTC (permalink / raw) To: egcs _Please_ include some means of allowing Fortran (at least) to get stack-allocated doubles double-aligned on x86 (modulo libc). (I hope I haven't missed this going in at some stage!) The one-line patch for STACK_BOUNDARY used by g77 0.5.22 is good enough. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-19 11:57 ` Dave Love @ 1998-06-21 21:43 ` Craig Burley 1998-06-21 23:07 ` Jeffrey A Law 1 sibling, 0 replies; 47+ messages in thread From: Craig Burley @ 1998-06-21 21:43 UTC (permalink / raw) To: egcs >_Please_ include some means of allowing Fortran (at least) to get >stack-allocated doubles double-aligned on x86 (modulo libc). (I hope >I haven't missed this going in at some stage!) The one-line patch for >STACK_BOUNDARY used by g77 0.5.22 is good enough. I agree this is important to fix, but ideally fix right. I'll look into this again when a more recent snapshot appears, but my experiments this past week didn't revealed any easy wins, though I don't recall trying the STACK_BOUNDARY fix. (By "fix right" I mean get 64-bit alignment for doubles as long as that won't break any ABIs. I don't mind special-casing some of this in g77, but imagine that's not the hard part. Basically all local and static VAR_DECLs should be 64-bit aligned when they're DFmode, but should remain 32-bit aligned when they're FIELD_DECLs and in the TYPE_DECL for the type as seen elsewhere, so g77 gets its common block and equivalence alignments right.) I've put together a Fortran program to report on these issues, but need to do a bit more work on it first before sending it along. tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-19 11:57 ` Dave Love 1998-06-21 21:43 ` Craig Burley @ 1998-06-21 23:07 ` Jeffrey A Law 1998-06-22 5:19 ` David S. Miller ` (2 more replies) 1 sibling, 3 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-21 23:07 UTC (permalink / raw) To: Dave Love; +Cc: egcs In message < rzqaf79nru7.fsf@djlvig.dl.ac.uk >you write: > _Please_ include some means of allowing Fortran (at least) to get > stack-allocated doubles double-aligned on x86 (modulo libc). (I hope > I haven't missed this going in at some stage!) The one-line patch for > STACK_BOUNDARY used by g77 0.5.22 is good enough. I'm still waiting on some kind of solution that doesn't totally break the ABI. To do this "right" you have to: * Make sure gcc always allocates stack in multiples of 8 bytes, adding dummy outgoing args as necessary to keep the stack properly aligned at call points. You can't do this with STACK_BOUNDARY since that says we will 100% always have a properly aligned stack, which can never be true since we might be linking in code from another compiler which didn't keep the stack suitably aligned. If the stack gets mis-aligned relative to STACK_BOUNDARY combine could end up removing a seemingly useless stack operation/address calculation. The idea is to make sure the stack is 8 byte aligned in the common cases, but not absolutely rely on it for correct code generation. * Second, assuming that gcc always keeps the pointer aligned for itself, then arrange for doubles to end up 8 byte aligned relative to the stack pointer. If the stack gets mis-aligned due to an old module, then our doubles won't be aligned correctly, but the vast majority of the time they will be suitably aligned. I don't think there's any mechanism to do this when the desired alignment is less than STACK_BOUNDARY. I fact I know that to be the case since I worked on a similar problem recently. * The ABI is still going to mandate that some doubles in argument lists are going to be mis-aligned. We'd have to arrange to copy them from the arglist into a suitable stack slot. This may be more trouble than its worth. Note that some non-ABI breaking changes to align doubles and other values have gone into the x86 compiler. In particular we should be properly aligning all data in the static store. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-21 23:07 ` Jeffrey A Law @ 1998-06-22 5:19 ` David S. Miller 1998-06-22 12:04 ` Dave Love ` (2 more replies) 1998-06-22 12:04 ` ix86 `double' " Craig Burley 1998-06-22 12:04 ` egcs-1.1 release schedule Dave Love 2 siblings, 3 replies; 47+ messages in thread From: David S. Miller @ 1998-06-22 5:19 UTC (permalink / raw) To: law; +Cc: d.love, egcs Date: Sun, 21 Jun 1998 22:31:31 -0600 From: Jeffrey A Law <law@cygnus.com> * The ABI is still going to mandate that some doubles in argument lists are going to be mis-aligned. We'd have to arrange to copy them from the arglist into a suitable stack slot. This may be more trouble than its worth. And there are still going to be issues with equivalence statements. Later, David S. Miller davem@dm.cobaltmicro.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-22 5:19 ` David S. Miller @ 1998-06-22 12:04 ` Dave Love 1998-06-22 13:45 ` Toon Moene 1998-06-22 18:20 ` ix86 double alignment (was Re: egcs-1.1 release schedule) Craig Burley 2 siblings, 0 replies; 47+ messages in thread From: Dave Love @ 1998-06-22 12:04 UTC (permalink / raw) To: egcs >>>>> "David" == David S Miller <davem@dm.cobaltmicro.com> writes: David> And there are still going to be issues with equivalence statements. I'm not sure specifically about equivalence with g77, but Fortran which depends on storage association which forces double precision variables to be misaligned is inherently non-portable (even if standard-conforming). For instance, g77 on SPARC (like other compilers and other systems) pads common blocks if necessary, the same as you get with -malign-double on x86; the canonical 20-year-old code breaks. Compilers do warn you, though many users choose to disbelieve them... ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-22 5:19 ` David S. Miller 1998-06-22 12:04 ` Dave Love @ 1998-06-22 13:45 ` Toon Moene 1998-06-22 22:29 ` Jeffrey A Law 1998-06-22 18:20 ` ix86 double alignment (was Re: egcs-1.1 release schedule) Craig Burley 2 siblings, 1 reply; 47+ messages in thread From: Toon Moene @ 1998-06-22 13:45 UTC (permalink / raw) To: David S. Miller; +Cc: egcs [ Welcome to the world of the 32-bit wonders of incongruence ] David "Sparc" Miller wrote: > Date: Sun, 21 Jun 1998 22:31:31 -0600 From: Jeffrey > A Law <law@cygnus.com> > * The ABI is still going to mandate that some > doubles in > argument lists are going to be mis-aligned. > We'd have to arrange to copy them from the > arglist into a suitable stack slot. This > may be more trouble than its worth. > And there are still going to be issues with equivalence > statements. Sure. But folks doing that should *know* they're invoking suboptimal behaviour. OTOH, this way we could teach them ;-) Cheers, Toon. PS: I agree with Jeff (even I don't know all the details - but I love to have them to get my little brother finish his PhD thesis in time :-) that the general problem simply is too hard (just consider an odd number of arguments-passed-by-reference). ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-22 13:45 ` Toon Moene @ 1998-06-22 22:29 ` Jeffrey A Law 0 siblings, 0 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-22 22:29 UTC (permalink / raw) To: Toon Moene; +Cc: David S. Miller, egcs In message < 9806222039.AA04066@moene.indiv.nluug.nl >you write: > PS: I agree with Jeff (even I don't know all the details Quick lesson then :-) Ignore if you're not really interested in the guts of why increasing STACK_BOUNDARY is a bad idea. GCC assumes that the stack pointer must always be a multiple of STACK_BOUNDARY. And it even has optimizations which use that info. combine will actually notice cases where the masking off of low bits should be unnecessary due to the value of STACK_BOUNDARY. ie if STACK_BOUNDARY is 64, then ((sp + x) & 0xfffffffc)) can be resolved to just (sp + x) (assuming X is a multiple of STACK_BOUNDARY). This optimization will generate code which does not work if somehow we get into a function where the stack is improperly aligned. The canonical example would be a callback from libc like the comparison routine for qsort. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* ix86 double alignment (was Re: egcs-1.1 release schedule) 1998-06-22 5:19 ` David S. Miller 1998-06-22 12:04 ` Dave Love 1998-06-22 13:45 ` Toon Moene @ 1998-06-22 18:20 ` Craig Burley 1998-06-23 3:32 ` David S. Miller 1998-06-23 3:32 ` Jeffrey A Law 2 siblings, 2 replies; 47+ messages in thread From: Craig Burley @ 1998-06-22 18:20 UTC (permalink / raw) To: davem; +Cc: law, d.love, egcs > Date: Sun, 21 Jun 1998 22:31:31 -0600 > From: Jeffrey A Law <law@cygnus.com> > > * The ABI is still going to mandate that some doubles in > argument lists are going to be mis-aligned. We'd have > to arrange to copy them from the arglist into a suitable > stack slot. This may be more trouble than its worth. > >And there are still going to be issues with equivalence statements. Well, I'm willing to not try to do any special aligning for EQUIVALENCE and COMMON for now. If we can just get 64-bit alignment for stack-allocated VAR_DECLs -- which generally won't include EQUIVALENCE (and certainly not COMMON) -- we'll have made a *huge* improvement in g77 performance, especially its *repeatability* of performance measurements. (Without this improvement, egcs 1.1 will often appear *substantially* worse than the combination of g77 0.5.22 and gcc 2.7.2.3 on lots of widely used Fortran code, assuming users are using -malign-double.) I hope to have a fairly thorough sample program put together soon (tomorrow?) to illustrate this, but the simple cases we want to align for now are like subroutine x double precision a ... end and: subroutine y(n) double precision a(n) ... end The latter uses automatic arrays (which gcc and g77 support), it'd be great to get those 64-bit aligned as well. The former is the most important thing we *aren't* aligning, currently, even with `-malign-double'. (It should be aligned especially if `a' is an array, of course.) A case we can't 64-bit align is: real r(2) double precision d1, d2 equivalence (r(1),d1) equivalence (r(2),d2) Regardless of whether this is stack, static, or even part of a common block, we can't 64-bit align both d1 and d2. (Well, not without an option to completely change the way we implement Fortran; I wonder if Sun does that to support weird-but-conforming code on SPARCs, such as the above.) What we *can* do is *implement* the above, perhaps warning about the suboptimal alignment. That is, there's no reason we can't go ahead and 32-bit align d1 and d2, so one of them is not 64-bit aligned. The programmer asked for it, after all! What we can also 64-bit align is this: real r(2) double precision d equivalence (r(2),d) We can do that because we can see that there are no actual *conflicts* of alignment. We can implement this by either inserting a dummy unused 32-bit variable before r(1) and aligning *that* to a 64-bit boundary (stack or static, doesn't matter), or, if we have a smart-enough back end (or linker, for static memory I guess), simply use a directive that means "align to a 64-bit boundary on bit 32". But it's not *important* to 64-bit align the above EQUIVALENCE case, certainly not for egcs 1.1. And what we also need to continue to support is stuff like real r1, r2 real s(6) double precision d1, d2 common r1, d1, r2, d2 equivalence (r1,s) which requires that s(1) overlays r1, s(2) and s(3) overlay d1, s(4) overlays r2, and s(5) and s(6) overlays d2. Again, we can do this by seeing that there are no "hard" conflicts (at the machine or ABI level), and punting (and warning?) over the fact that the "soft" conflicts (the ideal 64-bit alignment of double for performance reasons) prevent "ideal" alignment. Again, "so what", the programmer has specified no 64-bit alignment, so we don't give it to him in cases like that -- but we can still compile correct, and fairly fast, ABI-compatible, code. Note that I suggested the gcc architecture (machine descriptions, etc.) be modified to include a more fine-grained expression of alignment requirements. E.g. distinguishing hardware requirements (even instruction requirements, such as `ld' vs. `ldd' on SPARCv8) from ABI requirements from ideal performance settings. But this suggestion was turned down at the time -- some seven years ago! Maybe it's time we finally got this all "right", and I'm sure willing to help. But I think we can only manage to get a bit of it "right" to improve x86 performance for egcs 1.1. tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 double alignment (was Re: egcs-1.1 release schedule) 1998-06-22 18:20 ` ix86 double alignment (was Re: egcs-1.1 release schedule) Craig Burley @ 1998-06-23 3:32 ` David S. Miller 1998-06-23 6:30 ` Craig Burley 1998-06-23 3:32 ` Jeffrey A Law 1 sibling, 1 reply; 47+ messages in thread From: David S. Miller @ 1998-06-23 3:32 UTC (permalink / raw) To: burley; +Cc: law, d.love, egcs Date: Mon, 22 Jun 1998 14:29:42 -0400 (EDT) From: Craig Burley <burley@gnu.org> A case we can't 64-bit align is: real r(2) double precision d1, d2 equivalence (r(1),d1) equivalence (r(2),d2) Regardless of whether this is stack, static, or even part of a common block, we can't 64-bit align both d1 and d2. (Well, not without an option to completely change the way we implement Fortran; I wonder if Sun does that to support weird-but-conforming code on SPARCs, such as the above.) I can give some insight to this on certain cases on the Sparc. The UltraSparc has specific high performance trap vectors dedicated to handling the case where a double float load is done to an address which is not aligned correctly. The UltraSparc users manual suggests that if the compiler can determine that the likelyhood of bad alignment is 50/50 or less, if should output the double float loads. However there is an OS level side issue to this. Sparc is rather strict about unaligned loads by default on most systems I know about. However, most systems provide some way to tell the OS to "allow unaligned memory accesses, and fix them up for the program". This would need some investigation before such a scheme is enable in egcs, so I'd say defer thinking about it until after the 1.1 release happens. Later, David S. Miller davem@dm.cobaltmicro.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 double alignment (was Re: egcs-1.1 release schedule) 1998-06-23 3:32 ` David S. Miller @ 1998-06-23 6:30 ` Craig Burley 0 siblings, 0 replies; 47+ messages in thread From: Craig Burley @ 1998-06-23 6:30 UTC (permalink / raw) To: davem; +Cc: law, d.love, toon, egcs > Date: Mon, 22 Jun 1998 14:29:42 -0400 (EDT) > From: Craig Burley <burley@gnu.org> > > A case we can't 64-bit align is: > > real r(2) > double precision d1, d2 > equivalence (r(1),d1) > equivalence (r(2),d2) > > Regardless of whether this is stack, static, or even part of a common > block, we can't 64-bit align both d1 and d2. (Well, not without > an option to completely change the way we implement Fortran; I wonder > if Sun does that to support weird-but-conforming code on SPARCs, > such as the above.) > >I can give some insight to this on certain cases on the Sparc. [...] >This would need some investigation before such a scheme is enable in >egcs, so I'd say defer thinking about it until after the 1.1 release >happens. Yes, let me make this clear. I brought up SPARC only to illustrate my awareness that this issue is a general one for all gcc targets in theory at least and in practice for at least two targets (x86 and SPARC), probably others as well (`sh', whatever that is, already seems to have its own work done in this area...can someone send me a `sh' machine please? ;-). I am *not* recommending any of the changes we're discussing actually applying to code generation on SPARCs at all, at least not in the short term (1.1). In particular, while this align-doubles-properly-or-performance-will- really-really-suck issue has *frequently* come to my attention for the x86 architecture, basically *never* can I recall anyone complaining about not being able to compile real Fortran code using standard- conforming (but, as Dave Love rightly points out, nonportable due to machines like SPARC) constructs like the one I illustrated above. My impression: SPARC users, even of g77, have already been "trained" by Sun to not expect some weird force-bad-alignment code to work on that architecture. So they don't complain to us, either. (And, yes, there is a way to "fix" this problem: provide a command-line option that the compiler handles by making all ints and floats 64-bit, all doubles 128-bit, and adjusting the run-time libraries and so on accordingly. Not that the *precision* goes up, just that the Fortran INTEGER, LOGICAL, and REAL types suddenly have 32 useful bits and 32 junk bits in 64 bits of space, DOUBLE PRECISION and COMPLEX have 64+64 bits, and so on. With only a relatively small amount of hair, this makes full Fortran standards conformance possible, and makes most data needs expand by a factor of two with no increase in precision or range and a general decrease in run-time performance. A great way to discourage people from insisting that their old codes run without modification. Can't recall what I've been told, if anything, about whether Sun provides such an option in any of its Fortran compilers. Perhaps just the *threat* of "solving" this problem this way is all that has ever been needed, like the cold-war MAD policy regarding use of nuclear armaments. But I can't recall anybody asking for this option in g77, though I might be so quick to say "fine, send us lots of money" that I forgot all about any such requests. :) So, the tempting thing some people have thought is "well, SPARC users are used to a `broken' Fortran implementation for years, being happier with the performance gains; why not foist this on Intel users?" Unfortunately, the existing user base, library code, and iron base makes this worth solving for only newer instances of those, but not worth breaking for the older ones. The upshot: when [56]86 users aren't using "dangerous" options like `-malign-double', we still need to do 64-bit alignment wherever possible but without breaking compatibility to get decent performance. BTW, as much as I want this problem "cured" for [56]86 users in egcs 1.1, I *really* hope the libm performance problems on Alpha are generally fixed by the time such a version of egcs is released, because it disturbs me a bit that we might make [56]86 appear even better price/performance-wise than Alphas than they have in the past, especially since we *know* we can speed up the Alphas more than the [56]86 just by fixing just the software. (And, intentionally, I've kept the Alpha architecture manual within reach, but not the ix86 one so, for over a year now. :) tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 double alignment (was Re: egcs-1.1 release schedule) 1998-06-22 18:20 ` ix86 double alignment (was Re: egcs-1.1 release schedule) Craig Burley 1998-06-23 3:32 ` David S. Miller @ 1998-06-23 3:32 ` Jeffrey A Law 1998-06-23 5:13 ` Craig Burley 1 sibling, 1 reply; 47+ messages in thread From: Jeffrey A Law @ 1998-06-23 3:32 UTC (permalink / raw) To: Craig Burley; +Cc: davem, d.love, egcs In message < 199806221829.OAA07477@melange.gnu.org >you write: > Well, I'm willing to not try to do any special aligning for > EQUIVALENCE and COMMON for now. If we can just get 64-bit > alignment for stack-allocated VAR_DECLs -- which generally > won't include EQUIVALENCE (and certainly not COMMON) -- we'll > have made a *huge* improvement in g77 performance, especially > its *repeatability* of performance measurements. Yup. But considering the release schedule, I'd be happy if we could just get the stack aligned properly without breaking the ABI, then iterate to getting automatic variables aligned relative to the stack. If we can get more done before the release, then great, but I wouldn't want to hold things up on this issue if we can avoid it. > (Without this improvement, egcs 1.1 will often appear *substantially* > worse than the combination of g77 0.5.22 and gcc 2.7.2.3 on lots of > widely used Fortran code, assuming users are using -malign-double.) Well, we still have -malign-double as an option for the x86 port, so if they use it they presumably would see comparable performance, right? Actually, I'd expect generally better performance because we do handle alignments for static store items in a reasonable manner, which is a significant improvement by itself). > Note that I suggested the gcc architecture (machine descriptions, > etc.) be modified to include a more fine-grained expression of > alignment requirements. E.g. distinguishing hardware requirements > (even instruction requirements, such as `ld' vs. `ldd' on SPARCv8) > from ABI requirements from ideal performance settings. But this > suggestion was turned down at the time -- some seven years ago! Sigh. Yea, it really seems like something we should have -- then again, there's been little gcc emphasis on the x86 in the past and it's the most likely benefactor of such stuff. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 double alignment (was Re: egcs-1.1 release schedule) 1998-06-23 3:32 ` Jeffrey A Law @ 1998-06-23 5:13 ` Craig Burley 0 siblings, 0 replies; 47+ messages in thread From: Craig Burley @ 1998-06-23 5:13 UTC (permalink / raw) To: law; +Cc: davem, d.love, egcs [Need to study your later email with more technical issues more carefully next, but here are some quick points.] > In message < 199806221829.OAA07477@melange.gnu.org >you write: > > Well, I'm willing to not try to do any special aligning for > > EQUIVALENCE and COMMON for now. If we can just get 64-bit > > alignment for stack-allocated VAR_DECLs -- which generally > > won't include EQUIVALENCE (and certainly not COMMON) -- we'll > > have made a *huge* improvement in g77 performance, especially > > its *repeatability* of performance measurements. >Yup. But considering the release schedule, I'd be happy if we could >just get the stack aligned properly without breaking the ABI, then >iterate to getting automatic variables aligned relative to the stack. I'd say getting the stack aligned properly without breaking the ABI and *also* getting VAR_DECLs that are type `double' aligned within those frames (whether arrays or scalars) is not only the most important combination, but solves ~95% of the problems the g77 user community sees. At least getting this to work when -malign-double is specified would be kind of a "minimum" for making egcs 1.1 not noticably much worse than g77 0.5.21 and 0.5.22 were. >If we can get more done before the release, then great, but I wouldn't >want to hold things up on this issue if we can avoid it. I, hesitantly, agree. Dave rightly points out that he and others have been yelling about this for, well, it seems like years now. I still have email from him (weeks ago) asking me to make a more noticable push for this on the egcs list, and am now sorry I didn't take his advice sooner. I can only plead insanity, I guess it's all those soccer balls I hit with my head playing for Scotland that makes my brain mushy (just kidding, that's another Craig Burley ;-). > > (Without this improvement, egcs 1.1 will often appear *substantially* > > worse than the combination of g77 0.5.22 and gcc 2.7.2.3 on lots of > > widely used Fortran code, assuming users are using -malign-double.) >Well, we still have -malign-double as an option for the x86 port, so >if they use it they presumably would see comparable performance, right? No. I haven't yet finished up my totally-over-engineered diagnostic program to expose all this, but the preliminary results are: g77 0.5.21, 0.5.22: - Without -malign-double, basically no doubles get aligned properly, with the exception of doubles that can be lazily aligned in COMMON (without conflicts; and I'm not quite sure why this is, maybe my program isn't working quite right, it could easily be an accident that these appear to be aligned, the sort of accident the new version of my program should make much less likely). - With -malign-double, stack-based doubles still not aligned properly, but static/COMMON ones are (even if it breaks the COMMON ABI). - With -malign-double -O, all doubles are aligned properly. This is surprising; I didn't realize one needed -O to get this. (And, yes, this breaks the COMMON ABI, etc.) g77 0.5.23, egcs 1.0.3: - Without -malign-double, no doubles get aligned properly. - With -malign-double, static and automatic doubles get aligned, but not stack. (Automatic are stack-based with dynamic size.) -O makes no difference. egcs 19980615: - Without -malign-double, only static doubles (and non-conflicting COMMON doubles) get aligned properly, the rest don't. - With -malign-double, same as g77 0.5.23 and egcs 1.0.3. So, the one huge improvement we should try to make for 1.1 is, IMO, to achieve this: - Without -malign-double, static, stack, and automatic doubles get aligned properly, but not if they're in EQUIVALENCE or COMMON blocks. (Basically, any VAR_DECL the back end sees.) - With -malign-double, same as g77 0.5.21 and 0.5.22 when -O is specified, except -O wouldn't be needed here. The ideal situation would be to align all doubles that aren't involved in ABI issues, but I think just doing the non-aggregate ones handles ~95% of the important performance cases (as I've said, and that's a *real* seat-of-the-pants guess). Then, the only reason to use -malign-double is when the user knows ABI issues are consistent across all pertinent modules (e.g. they're all compiled with -malign-double) and the last ounce of performance is needed. >Actually, I'd expect generally better performance because we do handle >alignments for static store items in a reasonable manner, which is a >significant improvement by itself). Right, which makes egcs *default* to better performance than the *default* for 0.5.22, but to *worse* performance than 0.5.22 with -malign-double, *even if -malign-double is used for egcs*. The reason is that egcs nor gcc 2.8 will align stack-based doubles (except automatics, i.e. dynamically-sized stack doubles). So that's the main performance "regression" we currently have, which means that at least getting -malign-double to align all doubles, including stack-based ones, would seem to be worth making a "required" item for egcs 1.1. But I still would prefer it if we wouldn't effectively persuade most users to risk using -malign-double just to get stack-based doubles aligned for reasonable performance, and the way to do that is to make alignment of stack-based (and automatic) doubles the default, again, as long as the ABI isn't broken. So not needing to use -malign-double to align stack-based doubles would be a *huge* win, making egcs 1.1 *obviously* better than g77 0.5.21, 0.5.22, or 0.5.23 for most g77 users on x86. That's because lots of g77 users probably benchmark without reading up on (or feeling safe about using) -malign-double. > > Note that I suggested the gcc architecture (machine descriptions, > > etc.) be modified to include a more fine-grained expression of > > alignment requirements. E.g. distinguishing hardware requirements > > (even instruction requirements, such as `ld' vs. `ldd' on SPARCv8) > > from ABI requirements from ideal performance settings. But this > > suggestion was turned down at the time -- some seven years ago! >Sigh. Yea, it really seems like something we should have -- then >again, there's been little gcc emphasis on the x86 in the past and >it's the most likely benefactor of such stuff. When I asked for it, I thought it would have helped with the SPARC system I was working on at the time. Though, I might have been wrong. The x86 surely seems to have the most variety of alignment flavors I've ever seen for any given type: e.g. `double' alone has at least three alignments, 1 byte (minimum hardware alignment), 4 bytes (ABI alignment), and 8 bytes (ideal performance alignment)! If you really want to see how sick I am about this "let's architect the thing right so programmers have distinct things to specify, instead of one-size-fits-all straitjackets", take a look at the (now-ancient) g77 internals in this area. E.g. egcs/gcc/f/target.h. You'll find it not only tracks the alignment for each type, but the "modulo". That is, g77 can be taught (if given a suitable back end ;-) that a given type is to be aligned such that it begins on byte M of an N-byte-aligned block. gcc and other tools are architected to always align on byte 0 of an N-byte-aligned block, but before I had worked on g77, I had some awareness of the possibility of, e.g., a 10-byte type whose *last* 8 bytes had to be 8-byte aligned, so the object as a whole would have to be aligned to byte 6 of an 8-byte block. Of course, this proved useful when cutting the code to handle oddly-alignable aggregates, though never yet for fundamental types. Specifically, aligning an EQUIVALENCE block such that REAL R must be immediately followed by DOUBLE PRECISION D fits neatly into this scheme. E.g. "EQUIVALENCE (R,S(1)), (D,S(2))" is something g77 can and does handle by intuiting that the entire EQUIVALENCE block must be aligned to byte 4 of an 8-byte- aligned block (assuming compiling for a SPARC, or with -malign-double on an x86, or any machine with 8-byte-aligned doubles and 4-byte long floats). That means g77 can also handle "COMMON C, D", where C is CHARACTER*1 and D is DOUBLE PRECISION, though it warns that it has to insert pre-padding (of 7 bytes, usually) between the linker's idea of where the common block starts and where it actually starts (where C starts). (The warning is in case the same common area is declared with a different type layout, resulting in a different pre-padding being used, e.g. none.) And, by "sick" I mean I designed it this way back around 1988, before seeing barely a shred of GNU code! My usual philosophy is: if I can't think of *one* clear-cut meaning for a value, that usually means I shouldn't be using just *one* value (or constant or macro or whatever). gcc's DECL_ALIGN field, and the relevant muck, violates that principle in spades, of course. tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* ix86 `double' alignment (was Re: egcs-1.1 release schedule) 1998-06-21 23:07 ` Jeffrey A Law 1998-06-22 5:19 ` David S. Miller @ 1998-06-22 12:04 ` Craig Burley 1998-06-23 3:32 ` Jeffrey A Law 1998-06-22 12:04 ` egcs-1.1 release schedule Dave Love 2 siblings, 1 reply; 47+ messages in thread From: Craig Burley @ 1998-06-22 12:04 UTC (permalink / raw) To: law; +Cc: d.love, egcs > In message < rzqaf79nru7.fsf@djlvig.dl.ac.uk >you write: > > _Please_ include some means of allowing Fortran (at least) to get > > stack-allocated doubles double-aligned on x86 (modulo libc). (I hope > > I haven't missed this going in at some stage!) The one-line patch for > > STACK_BOUNDARY used by g77 0.5.22 is good enough. >I'm still waiting on some kind of solution that doesn't totally break >the ABI. I'm willing to do some serious work to make this happen for 1.1, which assumes it can be done in the next couple of weeks, right? >To do this "right" you have to: > > * Make sure gcc always allocates stack in multiples of 8 bytes, > adding dummy outgoing args as necessary to keep the stack > properly aligned at call points. > > You can't do this with STACK_BOUNDARY since that says we > will 100% always have a properly aligned stack, which can > never be true since we might be linking in code from > another compiler which didn't keep the stack suitably > aligned. For Fortran code, we can usually hand-wave that; this case would only come up when the call tree has an *embedded* procedure that doesn't maintain proper alignment, and since the big computational problem with g77 performance is in code compiled by g77, and such code is rarely called by C code, I don't think this would represent a huge deficiency. > If the stack gets mis-aligned relative to STACK_BOUNDARY > combine could end up removing a seemingly useless > stack operation/address calculation. I don't understand this, but presumably I need to look into it further. > The idea is to make sure the stack is 8 byte aligned in the > common cases, but not absolutely rely on it for correct code > generation. Absolutely. > * Second, assuming that gcc always keeps the pointer aligned > for itself, then arrange for doubles to end up 8 byte > aligned relative to the stack pointer. > > If the stack gets mis-aligned due to an old module, then > our doubles won't be aligned correctly, but the vast majority > of the time they will be suitably aligned. > > I don't think there's any mechanism to do this when the > desired alignment is less than STACK_BOUNDARY. I fact > I know that to be the case since I worked on a similar > problem recently. Okay, that makes sense to me. We want to hit a majority of cases anyway. We don't care (for now) about cases where users are combining multiple languages in weird ways, for example. > * The ABI is still going to mandate that some doubles in > argument lists are going to be mis-aligned. We'd have > to arrange to copy them from the arglist into a suitable > stack slot. This may be more trouble than its worth. I'm not sure how this can ever happen in the x86 architecture? Well, I mean, not when passing argument by reference, which is generally how g77 works anyway. >Note that some non-ABI breaking changes to align doubles and other >values have gone into the x86 compiler. In particular we should be >properly aligning all data in the static store. Right. The Next Big Thing is to, by default, 64-bit-align any stack-based VAR_DECLs. Just doing that would be Great. What I'd like to see, and think wouldn't be too hard, is a change that'd leave TYPE_ALIGN for doubles at 32, so g77 would still be able to produce COMMON and EQUIVALENCE blocks ("aggregates") containing doubles without breaking the ABI or rejecting standard-conforming code. (Never mind that g77 already does this for systems like SPARC; SPARC users expect that, apparently, while x86 users don't, mostly.) But this change would set DECL_ALIGN for stack-based VAR_DECLs to 64, and implement that, presumably by assuring that the stack frame is itself 64-bit aligned. What I don't know (having not looked into it in any detail) is how best to ensure the stack frame is 64-bit aligned. Presumably %sp will always be 32-bit aligned upon entry to any procedure (according to the ABI; perhaps the hardware?). Is it reasonable to just subtract an extra 8 bytes when creating the frame pointer upon procedure entry and then NAND it with 7 to align it? Or would that make for problems with debugger, profiling, and/or exception support, or is there no quick way to NAND the frame pointer on the x86? It seems like everyone else thinks the right way to do this is to try to always assure %sp is 64-bit aligned across calls by modifying all the code that is in the procedure-call chain. That probably means an extra dummy push before odd-number-of-args calls, etc., right? The reason I'd generally prefer the former approach to the latter is that either one is likely to cost some performance, but the latter *always* costs performance since the caller doesn't know whether the callee uses doubles, whereas the former costs only when the procedure doing the extra dance actually uses doubles. (Whether we can teach gcc to not do the NAND(%fp,7) if there are no doubles on the stack is another issue.) tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule) 1998-06-22 12:04 ` ix86 `double' " Craig Burley @ 1998-06-23 3:32 ` Jeffrey A Law 1998-06-23 5:13 ` Craig Burley 0 siblings, 1 reply; 47+ messages in thread From: Jeffrey A Law @ 1998-06-23 3:32 UTC (permalink / raw) To: Craig Burley; +Cc: d.love, egcs In message < 199806221811.OAA07410@melange.gnu.org >you write: > For Fortran code, we can usually hand-wave that; this case would > only come up when the call tree has an *embedded* procedure > that doesn't maintain proper alignment, and since the big > computational problem with g77 performance is in code compiled > by g77, and such code is rarely called by C code, I don't think > this would represent a huge deficiency. Right, but changing STACK_BOUNDARY is not an option because it does effect C code. > > If the stack gets mis-aligned relative to STACK_BOUNDARY > > combine could end up removing a seemingly useless > > stack operation/address calculation. > > I don't understand this, but presumably I need to look into it > further. I explained it a little in a message to Toon. Basically combine knows have to remove a rundant "and" operation which just turns off some low order bits in an address. If the stack isn't aligned to STACK_BOUNDARY, then combine could end up removing a mask operation that wasn't redundant. > Okay, that makes sense to me. We want to hit a majority of cases > anyway. We don't care (for now) about cases where users are > combining multiple languages in weird ways, for example. Well, we care about it from a correctness standpoint. Things still have to work if they're combining .o files from old compilers, callback from the library like qsort, etc. But we aren't really worred about performance in those cases. > > > * The ABI is still going to mandate that some doubles in > > argument lists are going to be mis-aligned. We'd have > > to arrange to copy them from the arglist into a suitable > > stack slot. This may be more trouble than its worth. > > I'm not sure how this can ever happen in the x86 architecture? Sure. Think about cases where the alignment of the double in the arglist isn't naturally aligned (think C, pass by value :-). foo (double, int) we push args back to front. So we push the int on the stack, which means the double will be at only a 4 byte aligned stack address if we assume our stack was 8 byte aligned before we pushed the args. You might think we could compensate for this by pushing an extra dummy word before the first integer to ensure the double gets aligned. But that loses if we have: foo (int2, double, int1) If we pushed an extra 4 byte hunk before int1, then the total size of the arglist would be 20 bytes -- not a multiple of 8. And as I'll explain below, we must always make sure to allocate in 8 byte lumps -- we can't depend on the callee to round the stack. > Is it reasonable > to just subtract an extra 8 bytes when creating the frame > pointer upon procedure entry and then NAND it with 7 to align > it? Or would that make for problems with debugger, profiling, > and/or exception support, or is there no quick way to NAND the > frame pointer on the x86? Nope. Because you then don't have a constant offset to get to the arguments that were passed to the function. To make this work you'd have to dedicate a hard register to serve as an argument pointer, which will be horrible. [ Think about it, how can you generate code to find an argument if at entry to the procedure you may adjust the stack by a varying value (0 or 4). ] Instead we must make sure that we always allocate stacks in 8 byte hunks in the prologue *and* that we push an extra dummy word on the stack when performing function calls where the arg list + return pointer are not a multiple of 8 bytes in size. [ Remember, the call itself will push a 4 byte word on the stack too, so we have to account for it too. ] > It seems like everyone else thinks the right way to do this is > to try to always assure %sp is 64-bit aligned across calls by > modifying all the code that is in the procedure-call chain. > That probably means an extra dummy push before odd-number-of-args > calls, etc., right? Close. It's not the number of args, but the total size of the arg list. If the size of the arg list is a multiple of 8 bytes, then we have to push a dummy arg. so that in the stack is 8 byte aligned when we enter the callee. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule) 1998-06-23 3:32 ` Jeffrey A Law @ 1998-06-23 5:13 ` Craig Burley 1998-06-24 2:28 ` Jeffrey A Law 0 siblings, 1 reply; 47+ messages in thread From: Craig Burley @ 1998-06-23 5:13 UTC (permalink / raw) To: law; +Cc: d.love, egcs > > > If the stack gets mis-aligned relative to STACK_BOUNDARY > > > combine could end up removing a seemingly useless > > > stack operation/address calculation. > > > > I don't understand this, but presumably I need to look into it > > further. >I explained it a little in a message to Toon. Basically combine knows >have to remove a rundant "and" operation which just turns off some >low order bits in an address. If the stack isn't aligned to >STACK_BOUNDARY, then combine could end up removing a mask operation >that wasn't redundant. I'm a little curious, though, how such an operation comes to pass. Is it only likely because the user code does something like "&foo & 7", or are there internally-generated reasons? It's okay if you can't think of any examples; I agree with the overall sentiment that we don't want to lie to the compiler in this area, even if we can't come up with a reason it'd bite us right away! > > Okay, that makes sense to me. We want to hit a majority of cases > > anyway. We don't care (for now) about cases where users are > > combining multiple languages in weird ways, for example. >Well, we care about it from a correctness standpoint. Things still >have to work if they're combining .o files from old compilers, >callback from the library like qsort, etc. But we aren't really >worred about performance in those cases. I came up with worse examples. If STACK_BOUNDARY (or anything that might break the ABI) is adjusted based on whether the processor is [56]86 vs. [34]86, then code/libraries that happen to be compiled on different variants of the x86 architecture could be magically incompatible, producing subtly wrong results. The other bad one is if we made only the g77 compiler "break" the ABI to get this performance the "easy way", then some poor user believed the g77 docs about f2c compatibility and tried to link f2c-and-gcc-compiled code with g77-compiled code. Even on the same machine with the same version of gcc/g77 (egcs 1.1, if we went down this rat-hole :), the result would be a subtly broken executable, because the g77-compiled code would lay out its COMMON areas differently than the f2c-and-gcc-compiled code! >Sure. Think about cases where the alignment of the double in the >arglist isn't naturally aligned (think C, pass by value :-). > >foo (double, int) > >we push args back to front. > >So we push the int on the stack, which means the double will be >at only a 4 byte aligned stack address if we assume our stack >was 8 byte aligned before we pushed the args. Note that, in practice, what g77 most often does is: foo (double *, int *) But, aside from that... My question is, just why, *conceptually*, is it a problem on the x86 architecture to try to align the argument list so the caller frame is 64-bit aligned *and* at least some of the doubles in the list are 64-bit aligned, but some aren't? That is, is there a reason that x86 code *must* be generated either to always assume doubles are 32-bit aligned *or* are always 64-bit aligned? I can't think of any. If that's the case, then IMO this whole problem is indeed, as I thought, the result of gcc just not having a flexible-enough architecture, that is, its "housekeeping staff" can't cope with meeting these meetable requirements. So can we at least come up with a short-term way to say "*try* to align outgoing doubles to 64-bits, but don't assume incoming doubles are 64-bit aligned", and in the long run make a better overall architecture for representing alignments? (Do I need to write a "white paper" on what I mean by all this -- would that help anyone understand what I'm talking about? I've thought it through quite a bit lately, so I could probably bang it out with a few days' work.) >You might think we could compensate for this by pushing an extra >dummy word before the first integer to ensure the double gets >aligned. But that loses if we have: > >foo (int2, double, int1) > >If we pushed an extra 4 byte hunk before int1, then the total >size of the arglist would be 20 bytes -- not a multiple of 8. > >And as I'll explain below, we must always make sure to allocate >in 8 byte lumps -- we can't depend on the callee to round the stack. Again, what is the *real* problem with just doing what is currently done for that case, ending up with a misaligned double arg for the incoming procedure -- must it really assume its double is 64-bit aligned? Or is this really just an internal problem with gcc's housekeeping? (Guess I should start reading my 486 handbook again! :) > > Is it reasonable > > to just subtract an extra 8 bytes when creating the frame > > pointer upon procedure entry and then NAND it with 7 to align > > it? Or would that make for problems with debugger, profiling, > > and/or exception support, or is there no quick way to NAND the > > frame pointer on the x86? >Nope. Because you then don't have a constant offset to get to the >arguments that were passed to the function. To make this work >you'd have to dedicate a hard register to serve as an argument >pointer, which will be horrible. > >[ Think about it, how can you generate code to find an argument if > at entry to the procedure you may adjust the stack by a varying > value (0 or 4). ] Duh, okay, that's right. That's my limited SPARC/VLIW thinking tripping me up again. Even though they have the same problem, I don't think about it, because so often all the incoming arguments arrive in registers. (I have spent most of the last 13 years or so working on machines that have registers; I'd forgotten my earlier experiences working on machines with hardly any, sorry. :) >Instead we must make sure that we always allocate stacks in 8 byte >hunks in the prologue *and* that we push an extra dummy word on the stack >when performing function calls where the arg list + return pointer >are not a multiple of 8 bytes in size. > >[ Remember, the call itself will push a 4 byte word on the stack > too, so we have to account for it too. ] Right. Okay. > > It seems like everyone else thinks the right way to do this is > > to try to always assure %sp is 64-bit aligned across calls by > > modifying all the code that is in the procedure-call chain. > > That probably means an extra dummy push before odd-number-of-args > > calls, etc., right? >Close. It's not the number of args, but the total size of the arg >list. If the size of the arg list is a multiple of 8 bytes, then >we have to push a dummy arg. so that in the stack is 8 byte aligned >when we enter the callee. Well, if we can arrange for internal gcc housekeeping to do this by default, *without* having other gcc housekeeping assume that incoming double arguments, or the stack frame itself, are aligned, is that basically enough to cover what I've been asking for? (Note that, ideally, -malign-double would not be needed to do the above. I wouldn't mind a new option to disable that new behavior, but IMO it should be enabled by default.) Also, presumably we don't actually have to *push* an arg, but just subtract 4 from %esp, right? I am quite willing to do this work myself. But I say that well- knowing I'm not the best person for the job; just someone sufficiently enthused, with a spot of time, a Pentium II, a trackball, and half the g77 user base hounding me for the past couple of years, etc. etc. etc. So I'd need some initial hand-holding, probably. :) tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule) 1998-06-23 5:13 ` Craig Burley @ 1998-06-24 2:28 ` Jeffrey A Law 1998-06-24 14:50 ` Craig Burley 0 siblings, 1 reply; 47+ messages in thread From: Jeffrey A Law @ 1998-06-24 2:28 UTC (permalink / raw) To: Craig Burley; +Cc: d.love, egcs In message < 199806230722.DAA02276@melange.gnu.org >you write: > I'm a little curious, though, how such an operation comes to pass. The code to implement va_arg has address masking of this nature. I also believe it occurs internally to handle memory accesses smaller than 32bits on the alpha. > I came up with worse examples. If STACK_BOUNDARY (or anything that > might break the ABI) is adjusted based on whether the processor > is [56]86 vs. [34]86, then code/libraries that happen to be compiled > on different variants of the x86 architecture could be magically > incompatible, producing subtly wrong results. Yes. Though I would strongly recommend against ABI things changing based on the processor for this exact reason :-) > My question is, just why, *conceptually*, is it a problem on the > x86 architecture to try to align the argument list so the caller > frame is 64-bit aligned *and* at least some of the doubles in > the list are 64-bit aligned, but some aren't? > > That is, is there a reason that x86 code *must* be generated either > to always assume doubles are 32-bit aligned *or* are always > 64-bit aligned? I can't think of any. It's not an architecture issue, but an ABI issue. The architecture should be able to handle just about an alignment we throw at it. Basically the ABI just mandates a 4 byte alignment, we get better performance if we could get the args 8 byte aligned. But I'll be a little suprised if we can do this without having the callee copy it out of the arglist to an aligned memory slot. There is an interesting problem from a gcc internals standpoint that we may hit if we ever tried to align doubles relative to the start of the argument list. I ran into it on the v850 a couple years ago, but I don't remember the details. Basically the info we needed to do this wasn't available and the scheme broke down when handling varargs/stdarg. > So can we at least come up with a short-term way to say "*try* > to align outgoing doubles to 64-bits, but don't assume incoming > doubles are 64-bit aligned", and in the long run make a better > overall architecture for representing alignments? Let's defer trying to align arglists until we get the stack pointer itself aligned and until after we're aligning auto variables relative to the stack pointer and possibly stack slots for pseudos that don't get hard registers aligned :-) My gut tells me aligning variables inside the arglist isn't going to win as much as the other cases noted above. > >You might think we could compensate for this by pushing an extra > >dummy word before the first integer to ensure the double gets > >aligned. But that loses if we have: > > > >foo (int2, double, int1) > > > >If we pushed an extra 4 byte hunk before int1, then the total > >size of the arglist would be 20 bytes -- not a multiple of 8. > > > >And as I'll explain below, we must always make sure to allocate > >in 8 byte lumps -- we can't depend on the callee to round the stack. > > Again, what is the *real* problem with just doing what is currently > done for that case, ending up with a misaligned double arg for > the incoming procedure -- must it really assume its double is > 64-bit aligned? Or is this really just an internal problem with > gcc's housekeeping? There's no problem other than the performance issues. The code will still work. Maybe that's where we're mis-communicating :-) Before we can do *anything* about the alignment of args and autos we first need to get the stack pointer aligned at all times. Let's deal with that first, then try to come up with solutions for the auto and argument alignment afterwards. > >Instead we must make sure that we always allocate stacks in 8 byte > >hunks in the prologue *and* that we push an extra dummy word on the stack > >when performing function calls where the arg list + return pointer > >are not a multiple of 8 bytes in size. > > > >[ Remember, the call itself will push a 4 byte word on the stack > > too, so we have to account for it too. ] > > Right. Okay. OK. We agree on this. And since any work which involves trying to align autos depends on first getting the stack aligned let's solve the alignment of the stack pointer problem first. That work can happen while we debate the other issues :-) > Also, presumably we don't actually have to *push* an arg, but just > subtract 4 from %esp, right? Right. We don't actually have to make the memory reference, just allocate an extra outgoing arg slot before we push any of the real outgoing arguments. > I am quite willing to do this work myself. But I say that well- > knowing I'm not the best person for the job; just someone sufficiently > enthused, with a spot of time, a Pentium II, a trackball, and > half the g77 user base hounding me for the past couple of years, > etc. etc. etc. So I'd need some initial hand-holding, probably. :) Well, I don't have the time to tackle it myself, but I can try to help you (or anyone else) through the twisty maze of ABI related code in gcc to try and make this happen. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule) 1998-06-24 2:28 ` Jeffrey A Law @ 1998-06-24 14:50 ` Craig Burley 1998-06-25 0:25 ` Jeffrey A Law 0 siblings, 1 reply; 47+ messages in thread From: Craig Burley @ 1998-06-24 14:50 UTC (permalink / raw) To: law; +Cc: d.love, toon, egcs >Basically the ABI just mandates a 4 byte alignment, we get better >performance if we could get the args 8 byte aligned. But I'll be >a little suprised if we can do this without having the callee copy >it out of the arglist to an aligned memory slot. I guess we shouldn't try aligning outoing/incoming doubles passed "by value" (C style) at all, now that I think about it more. It'd surely break the ABI. >My gut tells me aligning variables inside the arglist isn't going to >win as much as the other cases noted above. Especially not for Fortran, since g77 doesn't generally pass doubles (or anything) by value, with some exceptions for the run-time library. And, I suspect the real performance penalties come mostly from arrays and such inside loops anyway. People don't pass arrays by value (not usually ;-), and if an incoming by-value double is used frequently in a loop, all that's really needed is to make the compiler smart enough to make an aligned copy of that argument...but let's wait until we see real code that could benefit from that. > > Again, what is the *real* problem with just doing what is currently > > done for that case, ending up with a misaligned double arg for > > the incoming procedure -- must it really assume its double is > > 64-bit aligned? Or is this really just an internal problem with > > gcc's housekeeping? >There's no problem other than the performance issues. The code will >still work. Maybe that's where we're mis-communicating :-) Oh, okay, good, indeed we were. My priorities here are first to make sure nothing that does work stops working; second to make sure nothing reasonable suddenly goes lots slower; third to make lots of stuff go faster. Its the third priority we're discussing, of course, but some of the solutions that have been proposed (including, I though, mine) might violate the first two. But I now don't see how we can align doubles in an arglist while both aligning the callee's incoming stack frame *and* meeting the ABI requirements. After all, any arglist consisting of arbitrary float, double, and int (32-bit) must be laid out with no padding between args and no padding between the last-pushed arg (the first arg and the return address `call' pushes), right? The only way to ensure that the incoming stack frame is aligned is to optionally reserve a 4-byte pad before pushing any of the args, as we've discussed. So, AFAICT, the doubles end up where they end up, either aligned or not, and there's nothing we can do about it at that point. Of course, the callee can, as you point out, copy them to aligned locations on its stack frame and use that, which is worthwhile if it sees the potential for frequent references during the call. >Before we can do *anything* about the alignment of args and autos we >first need to get the stack pointer aligned at all times. Let's deal >with that first, then try to come up with solutions for the auto and >argument alignment afterwards. Uh-guh-reed! :) tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule) 1998-06-24 14:50 ` Craig Burley @ 1998-06-25 0:25 ` Jeffrey A Law 1998-06-25 9:59 ` Tim Hollebeek 1998-06-28 18:01 ` Marc Lehmann 0 siblings, 2 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-25 0:25 UTC (permalink / raw) To: Craig Burley; +Cc: d.love, toon, egcs In message < 199806241507.LAA11762@melange.gnu.org >you write: > >Basically the ABI just mandates a 4 byte alignment, we get better > >performance if we could get the args 8 byte aligned. But I'll be > >a little suprised if we can do this without having the callee copy > >it out of the arglist to an aligned memory slot. > > I guess we shouldn't try aligning outoing/incoming doubles passed > "by value" (C style) at all, now that I think about it more. It'd > surely break the ABI. Right. That's basically what I was trying to explain in one or more of those longer messages. You can't align stuff in the arglist without either breaking the ABI or blowing away the alignment we want for the stack pointer. > And, I suspect the real performance penalties come mostly from arrays > and such inside loops anyway. People don't pass arrays by value > (not usually ;-), and if an incoming by-value double is used > frequently in a loop, all that's really needed is to make the > compiler smart enough to make an aligned copy of that argument...but > let's wait until we see real code that could benefit from that. Right. It may also be the case that we'll need to align stack slots for pseudos that don't get hard regs. But that can wait until we determine its important. > So, AFAICT, the doubles end up where they end up, either aligned > or not, and there's nothing we can do about it at that point. Right. > >Before we can do *anything* about the alignment of args and autos we > >first need to get the stack pointer aligned at all times. Let's deal > >with that first, then try to come up with solutions for the auto and > >argument alignment afterwards. > > Uh-guh-reed! :) Yeppers. :-) jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule) 1998-06-25 0:25 ` Jeffrey A Law @ 1998-06-25 9:59 ` Tim Hollebeek 1998-06-28 18:01 ` Marc Lehmann 1 sibling, 0 replies; 47+ messages in thread From: Tim Hollebeek @ 1998-06-25 9:59 UTC (permalink / raw) To: law; +Cc: burley, d.love, toon, egcs Jeffrey A Law writes ... > > Right. That's basically what I was trying to explain in one or more > of those longer messages. You can't align stuff in the arglist without > either breaking the ABI or blowing away the alignment we want for the > stack pointer. Would it be possible to have the argument read from its unaligned location the first time it is used, but if it is ever spilled out of a register before it goes dead to have it written to an aligned location? This seems like a workable idea which is half way between the 'copy to an aligned location' and the 'always use the unaligned value' ideas. Might be a bitch to implement, though. --------------------------------------------------------------------------- Tim Hollebeek | "Everything above is a true email: tim@wfn-shop.princeton.edu | statement, for sufficiently URL: http://wfn-shop.princeton.edu/~tim | false values of true." ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule) 1998-06-25 0:25 ` Jeffrey A Law 1998-06-25 9:59 ` Tim Hollebeek @ 1998-06-28 18:01 ` Marc Lehmann 1 sibling, 0 replies; 47+ messages in thread From: Marc Lehmann @ 1998-06-28 18:01 UTC (permalink / raw) To: egcs On Wed, Jun 24, 1998 at 06:11:55PM -0600, Jeffrey A Law wrote: > > "by value" (C style) at all, now that I think about it more. It'd > > surely break the ABI. > Right. That's basically what I was trying to explain in one or more > of those longer messages. You can't align stuff in the arglist without > either breaking the ABI or blowing away the alignment we want for the > stack pointer. -malign-double already breaks the abi, and is reeeealy useful. considerung it doesn't cost anything at all to implement -marg-align-double (except fixing a bug/deficiency in calls.c). I'd guess people would be happy for the additional 1%. -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ --+ The choice of a GNU generation | | ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-21 23:07 ` Jeffrey A Law 1998-06-22 5:19 ` David S. Miller 1998-06-22 12:04 ` ix86 `double' " Craig Burley @ 1998-06-22 12:04 ` Dave Love 1998-06-23 3:32 ` Craig Burley 1998-06-23 3:32 ` Jeffrey A Law 2 siblings, 2 replies; 47+ messages in thread From: Dave Love @ 1998-06-22 12:04 UTC (permalink / raw) To: egcs >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes: Jeff> You can't do this with STACK_BOUNDARY since that says we Jeff> will 100% always have a properly aligned stack, I guess we've just been lucky with the previous g77. (BTW, perhaps the documentation of the alignment macros could be reviewed?) I thought there was an agreed patch available to do things right, too, which presumably I misunderstod about. Jeff> * The ABI is still going to mandate that some doubles in Jeff> argument lists are going to be mis-aligned. Fortunately that isn't much of an issue for Fortran :-). Jeff> Note that some non-ABI breaking changes to align doubles and Jeff> other values have gone into the x86 compiler. In particular we Jeff> should be properly aligning all data in the static store. Does that make -malign-double redundant? [In case people don't know, the point of this is that mis-aligned doubles on PIIs (with which some people want to do supercomputing) can apparently cost a factor of 2-3 in speed for real numerical code.] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-22 12:04 ` egcs-1.1 release schedule Dave Love @ 1998-06-23 3:32 ` Craig Burley 1998-06-23 3:32 ` Jeffrey A Law 1 sibling, 0 replies; 47+ messages in thread From: Craig Burley @ 1998-06-23 3:32 UTC (permalink / raw) To: d.love; +Cc: egcs > Jeff> Note that some non-ABI breaking changes to align doubles and > Jeff> other values have gone into the x86 compiler. In particular we > Jeff> should be properly aligning all data in the static store. > >Does that make -malign-double redundant? See my just-emailed long answer, but the short answer is "no". With -malign-double, g77 0.5.23, egcs 1.0, and the 19980615 snapshot align automatic and COMMON doubles. Without it, they don't. And, without it, g77 0.5.23 and egcs 1.0 don't even align static doubles! So the improvement in egcs 1.1-in-development is that -malign-double is not needed to align the static doubles, but there's still the automatic and, for okay-to-break-ABI cases, COMMON doubles to align, not to mention all those stack-based doubles (IMO probably the most important of the lot, but maybe you or others know better). However, none of these newer g77's align stack-based doubles *regardless* of -malign-double. That, *at least*, should be fixed in egcs 1.1, as it represents a serious regression even for performance-hungry g77 users who use -malign-double against g77 0.5.21 and 0.5.22. (Though with 0.5.2[12] they really have to use -O as well, though of course they would be anyway. I don't know why -O makes a difference, offhand.) tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-22 12:04 ` egcs-1.1 release schedule Dave Love 1998-06-23 3:32 ` Craig Burley @ 1998-06-23 3:32 ` Jeffrey A Law 1998-06-23 9:29 ` H.J. Lu 1 sibling, 1 reply; 47+ messages in thread From: Jeffrey A Law @ 1998-06-23 3:32 UTC (permalink / raw) To: Dave Love; +Cc: egcs In message < rzqiultp90m.fsf@djlvig.dl.ac.uk >you write: > >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes: > > Jeff> You can't do this with STACK_BOUNDARY since that says we > Jeff> will 100% always have a properly aligned stack, > > I guess we've just been lucky with the previous g77. (BTW, perhaps > the documentation of the alignment macros could be reviewed?) I > thought there was an agreed patch available to do things right, too, > which presumably I misunderstod about. I went back and reviewed Marc's patch. It had ABI issues to contend with. It was my mistake to say it didn't have ABI isssues a few months ago. Well, the optimizations which eliminate useless masks were in older versions of gcc, but they were much less aggressive. Kenner spent quite some time making them more aggressive (since I think it really helps the alpha). > Jeff> * The ABI is still going to mandate that some doubles in > Jeff> argument lists are going to be mis-aligned. > > Fortunately that isn't much of an issue for Fortran :-). True, but it is an issue for C :-) > Jeff> Note that some non-ABI breaking changes to align doubles and > Jeff> other values have gone into the x86 compiler. In particular we > Jeff> should be properly aligning all data in the static store. > > Does that make -malign-double redundant? I don't think so. I think -malign-double also effects stuff like alignment of doubles in structures and the like. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-23 3:32 ` Jeffrey A Law @ 1998-06-23 9:29 ` H.J. Lu 1998-06-24 17:12 ` x86 double alignment (was egcs-1.1 release schedule) Marc Lehmann 0 siblings, 1 reply; 47+ messages in thread From: H.J. Lu @ 1998-06-23 9:29 UTC (permalink / raw) To: law; +Cc: d.love, egcs > > > In message < rzqiultp90m.fsf@djlvig.dl.ac.uk >you write: > > >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes: > > > > Jeff> You can't do this with STACK_BOUNDARY since that says we > > Jeff> will 100% always have a properly aligned stack, > > > > I guess we've just been lucky with the previous g77. (BTW, perhaps > > the documentation of the alignment macros could be reviewed?) I > > thought there was an agreed patch available to do things right, too, > > which presumably I misunderstod about. > I went back and reviewed Marc's patch. It had ABI issues to contend > with. It was my mistake to say it didn't have ABI isssues a few months > ago. > I believe Marc's patch doesn't change ABI by default. But you can turn on some optimizations by hand which will change ABI. But if the user is warned, it shouldn't be a problem. Besides, he/she recompile libraries with the new ABI if Linux/xxxxBSD is used. H.J. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-23 9:29 ` H.J. Lu @ 1998-06-24 17:12 ` Marc Lehmann 1998-06-25 0:25 ` Jeffrey A Law ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Marc Lehmann @ 1998-06-24 17:12 UTC (permalink / raw) To: egcs On Tue, Jun 23, 1998 at 07:47:24AM -0700, H.J. Lu wrote: > > I believe Marc's patch doesn't change ABI by default. But you can Sorry for me first sending the patch and then reading the list ;) I actually have a backlog of >600 messages on egcs and just found this thread when Bernd asked me about the double-alignment patch. > turn on some optimizations by hand which will change ABI. But if The original patch turned on -mstack-align-double, which I thought is safe, but it isn't. I got a report from a windows user that it breaks most windows function semantics, as these functions deallocate the stack themselves. In this case, -mstack-align-double will break the program. If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions (like qsort or __libc_start) with it, so the problem of combine breaking code is solved, so we can either - document that -mno-stack-align-double should be used when linking against third-party-libs - not making it on by default. there are also speed issues, i.e. in integer-only programs, -mstack-align-double slows down code (a bit), so it should probably be disabled anyway. -marg-align-double never worked, due to limitations in calls.c (FUNCTION_ARG_BOUNDARY is effectively ignored on calls, but not within the called function), and breaks the abi, and was thus always optional. (it would align doubles in the argument area, this _severely_ breaks the abi, of course) -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ --+ The choice of a GNU generation | | ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-24 17:12 ` x86 double alignment (was egcs-1.1 release schedule) Marc Lehmann @ 1998-06-25 0:25 ` Jeffrey A Law 1998-06-28 18:02 ` Marc Lehmann 1998-06-25 12:33 ` PÃ¥l-Kristian Engstad 1998-06-25 21:48 ` Craig Burley 2 siblings, 1 reply; 47+ messages in thread From: Jeffrey A Law @ 1998-06-25 0:25 UTC (permalink / raw) To: Marc Lehmann; +Cc: egcs In message < 19980624192457.45730@cerebro.laendle >you write: > If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions > (like qsort or __libc_start) with it, so the problem of combine breaking code > is solved, so we can either Actually, if I remember the problem you described correctly, combine was doing the right thing. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-25 0:25 ` Jeffrey A Law @ 1998-06-28 18:02 ` Marc Lehmann 0 siblings, 0 replies; 47+ messages in thread From: Marc Lehmann @ 1998-06-28 18:02 UTC (permalink / raw) To: egcs On Thu, Jun 25, 1998 at 01:21:57AM -0600, Jeffrey A Law wrote: > > > In message < 19980624192457.45730@cerebro.laendle >you write: > > If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions > > (like qsort or __libc_start) with it, so the problem of combine breaking code > > is solved, so we can either > Actually, if I remember the problem you described correctly, combine was > doing the right thing. Combine is doing the right thing, yes. It does an unsafe optimization, but the machine description clearly says it can. I meant if egcs _had_ this switch, the functions using callback-functions could be compiled with it, so code that is compiled with -mstack-align-double is safe, even if called from libc. -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ --+ The choice of a GNU generation | | ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-24 17:12 ` x86 double alignment (was egcs-1.1 release schedule) Marc Lehmann 1998-06-25 0:25 ` Jeffrey A Law @ 1998-06-25 12:33 ` PÃ¥l-Kristian Engstad 1998-06-28 18:02 ` Marc Lehmann 1998-06-25 21:48 ` Craig Burley 2 siblings, 1 reply; 47+ messages in thread From: PÃÂ¥l-Kristian Engstad @ 1998-06-25 12:33 UTC (permalink / raw) To: Marc Lehmann, egcs Hi! Although double-alignment on stack variables would be a bad idea (for most situations), it would make perfect sense in certain situations. For instance, leaf functions could certainly benefit from being stack aligned. Also, functions which only call leaf functions that are stack aligned can use stack alignment. Would it be possible to do something like that? Also, if we are in a situation where we can not stack-align, the default behaviour for often used variables would be to make a copy onto the stack (double-aligned), and use this instead (unless it is only used as a register). PKE. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-25 12:33 ` PÃ¥l-Kristian Engstad @ 1998-06-28 18:02 ` Marc Lehmann 0 siblings, 0 replies; 47+ messages in thread From: Marc Lehmann @ 1998-06-28 18:02 UTC (permalink / raw) To: egcs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1060 bytes --] On Thu, Jun 25, 1998 at 11:13:45AM -0700, PÃ¥l-Kristian Engstad wrote: > Hi! > > Although double-alignment on stack variables would be a bad idea (for > most situations), it would make perfect sense in certain situations. > > For instance, leaf functions could certainly benefit from being stack > aligned. Also, functions which only call leaf functions that are stack > aligned can use stack alignment. I don't see why this is only beneficial for leaf functions? Any functions using doubles heavily benefits from this optimization. Unfortunately, its almost impossible to enforce stack alignment only for leaf functions.. -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ --+ The choice of a GNU generation | | ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-24 17:12 ` x86 double alignment (was egcs-1.1 release schedule) Marc Lehmann 1998-06-25 0:25 ` Jeffrey A Law 1998-06-25 12:33 ` PÃ¥l-Kristian Engstad @ 1998-06-25 21:48 ` Craig Burley 1998-06-25 18:53 ` Jeffrey A Law 1998-06-28 22:41 ` Marc Lehmann 2 siblings, 2 replies; 47+ messages in thread From: Craig Burley @ 1998-06-25 21:48 UTC (permalink / raw) To: pcg; +Cc: egcs, law >The original patch turned on -mstack-align-double, which I thought is safe, >but it isn't. I got a report from a windows user that it breaks most windows >function semantics, as these functions deallocate the stack themselves. In >this case, -mstack-align-double will break the program. Wait, how can these functions deallocate the stack themselves when the *caller* also is deallocating the stack, as is normally the case for x86-ABI code? Aren't these functions essentially violating the ABI in a way the compiler producing code that calls them *must* know about? What I haven't looked into yet is whether subtracting 4 from %esp before pushing args might upset some varargs/stdargs implementation on the callee side (that the caller doesn't know about), i.e. if that can even happen. >If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions >(like qsort or __libc_start) with it, so the problem of combine breaking code >is solved, so we can either > >- document that -mno-stack-align-double should be used when linking against third-party-libs >- not making it on by default. If it's not on by default, it's of only limited benefit, though that'd still take care of lots of Fortran users who are willing to learn about and use an option like -mstack-align-double. My feeling is that if -mstack-align-double doesn't break the ABI, then make it the default. Any bugs resulting from this are thus likely to be because *other* code breaks the ABI. Our compiler should be "told" about those codes explicitly anyway, via attributes or something. >there are also speed issues, i.e. in integer-only programs, -mstack-align-double >slows down code (a bit), so it should probably be disabled anyway. I was thinking earlier this week that, for example, the Linux kernel perhaps would run faster if -mno-stack-align-double was specified for compiling it. But, the problem is that if we don't make -mstack-align-double the default, lots of code that uses `double' will not get proper alignment and will continue have *big* performance degradation. >-marg-align-double never worked, due to limitations in calls.c (FUNCTION_ARG_BOUNDARY >is effectively ignored on calls, but not within the called function), and >breaks the abi, and was thus always optional. (it would align doubles in the >argument area, this _severely_ breaks the abi, of course) Yup, we pretty much ended up concluding this (I should say, I finally understood what others were saying). tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-25 21:48 ` Craig Burley @ 1998-06-25 18:53 ` Jeffrey A Law 1998-06-28 22:41 ` Marc Lehmann 1 sibling, 0 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-25 18:53 UTC (permalink / raw) To: Craig Burley; +Cc: pcg, egcs In message < 199806251615.MAA12029@melange.gnu.org >you write: > What I haven't looked into yet is whether subtracting 4 from %esp > before pushing args might upset some varargs/stdargs implementation > on the callee side (that the caller doesn't know about), i.e. if > that can even happen. I'm pretty sure it's safe. Even for varargs/stdarg. Basically think of it as having an extra int argument at the end of the arglist (remember we push back to front). An extra argument never hurt anyone :-) We do have to be careful and make sure we don't screw RETURN_POPS_ARGS support though. I'd forgotten about that. Though I do not think that adds any significant complexity to the problem. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-25 21:48 ` Craig Burley 1998-06-25 18:53 ` Jeffrey A Law @ 1998-06-28 22:41 ` Marc Lehmann 1998-06-29 5:20 ` Martin Kahlert ` (2 more replies) 1 sibling, 3 replies; 47+ messages in thread From: Marc Lehmann @ 1998-06-28 22:41 UTC (permalink / raw) To: egcs On Thu, Jun 25, 1998 at 12:15:17PM -0400, Craig Burley wrote: > >The original patch turned on -mstack-align-double, which I thought is safe, > >but it isn't. I got a report from a windows user that it breaks most windows > >function semantics, as these functions deallocate the stack themselves. In > >this case, -mstack-align-double will break the program. > > Wait, how can these functions deallocate the stack themselves when > the *caller* also is deallocating the stack, as is normally the it isn't: __attribute__((stdcall)). > case for x86-ABI code? Aren't these functions essentially violating > the ABI in a way the compiler producing code that calls them *must* > know about? the problem is we can't change the windows kernel. its a third-party product I'd really like to recompile ;) > >- document that -mno-stack-align-double should be used when linking against third-party-libs > >- not making it on by default. > > If it's not on by default, it's of only limited benefit, though that'd > still take care of lots of Fortran users who are willing to learn about > and use an option like -mstack-align-double. I had this on by default for half a year in pgcc (until I was told about windows having problems). It isn't beneficial for integer programs, and there are a great many of them around. I'm not happy with the idea of punishing a whole class of functions. If all third-party libraries (e.g. libc) were compiled with this switch (we only need to have this on for functions using callbacks), we could leave the choice up to the individual program. > My feeling is that if -mstack-align-double doesn't break the ABI, then > make it the default. Any bugs resulting from this are thus likely to be > because *other* code breaks the ABI. Our compiler should be "told" about > those codes explicitly anyway, via attributes or something. these codes are already available, and already used (in windows, at least, which means nothing too important to me, since code for that platform won't be distrivuted in binary to other systems I believe). The problem is mostly speed loss. > But, the problem is that if we don't make -mstack-align-double the > default, lots of code that uses `double' will not get proper > alignment and will continue have *big* performance degradation. Educate your users. I thought that way for a great long time, maybe I'm used to tweaking switches, but thats _already_ the case with loop unrolling or "-O3 vs. -O2". Why isn't loop unrolling on by default? Why Do most programs use -O2 when -O3 is faster? -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ --+ The choice of a GNU generation | | ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-28 22:41 ` Marc Lehmann @ 1998-06-29 5:20 ` Martin Kahlert 1998-06-29 11:08 ` Jeffrey A Law 1998-06-29 19:43 ` Craig Burley 1998-06-29 20:41 ` Craig Burley 1998-06-30 4:50 ` x86 double alignment (was egcs-1.1 release schedule) Jeffrey A Law 2 siblings, 2 replies; 47+ messages in thread From: Martin Kahlert @ 1998-06-29 5:20 UTC (permalink / raw) To: egcs Quoting Marc Lehmann (pcg@goof.com): > On Thu, Jun 25, 1998 at 12:15:17PM -0400, Craig Burley wrote: > > >The original patch turned on -mstack-align-double, which I thought is safe, > > >but it isn't. I got a report from a windows user that it breaks most windows > > >function semantics, as these functions deallocate the stack themselves. In > > >this case, -mstack-align-double will break the program. > > > > Wait, how can these functions deallocate the stack themselves when > > the *caller* also is deallocating the stack, as is normally the > > it isn't: __attribute__((stdcall)). > > > case for x86-ABI code? Aren't these functions essentially violating > > the ABI in a way the compiler producing code that calls them *must* > > know about? > > the problem is we can't change the windows kernel. its a third-party > product I'd really like to recompile ;) > A small dummy question: Is it possible without big efford, to only align automatic (local) double vars and leave all function parameters untouched? So no ABI gets violatet. Most time critical calculations aren't performed on stack doubles, i would imagine. Just a silly question. Bye, Martin. -- What is the difference between Jurassic Park and Microsoft? One is an over-rated high tech theme park based on prehistoric information and populated mostly by dinosaurs, the other is a Steven Spielberg movie. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-29 5:20 ` Martin Kahlert @ 1998-06-29 11:08 ` Jeffrey A Law 1998-06-29 19:43 ` Craig Burley 1 sibling, 0 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-29 11:08 UTC (permalink / raw) To: martin.kahlert; +Cc: egcs In message < 19980629141934.A18433@keksy.mchp.siemens.de >you write: > A small dummy question: Is it possible without big efford, > to only align automatic (local) double vars > and leave all function parameters untouched? So no ABI gets violatet. > Most time critical calculations aren't performed on stack doubles, > i would imagine. That is the current goal. "big effort" is a matter of interpretation :-) jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-29 5:20 ` Martin Kahlert 1998-06-29 11:08 ` Jeffrey A Law @ 1998-06-29 19:43 ` Craig Burley 1 sibling, 0 replies; 47+ messages in thread From: Craig Burley @ 1998-06-29 19:43 UTC (permalink / raw) To: martin.kahlert; +Cc: egcs >A small dummy question: Is it possible without big efford, >to only align automatic (local) double vars >and leave all function parameters untouched? So no ABI gets violatet. >Most time critical calculations aren't performed on stack doubles, >i would imagine. I think that's what we've been concensing on over the past week already -- 1) get the outgoing stack pointer aligned, so the callee gets an aligned stack frame of the caller had an aligned incoming %esp; 2) get double vars aligned within the stack frame; 3) don't do anything different with double vars passed to a called procedure, since otherwise we'd seriously break the ABI; 4) *maybe* use aligned, frame-based locations for *spills* of incoming double var args (so instead of spilling by not writing and just re-reading the original var from the arglist, spill by writing to an aligned stack temp slot and reading from that; which costs an extra write, but for lots of reads, gains from having those reads aligned). tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-28 22:41 ` Marc Lehmann 1998-06-29 5:20 ` Martin Kahlert @ 1998-06-29 20:41 ` Craig Burley 1998-06-30 0:42 ` Jeffrey A Law 1998-06-30 4:50 ` x86 double alignment (was egcs-1.1 release schedule) Jeffrey A Law 2 siblings, 1 reply; 47+ messages in thread From: Craig Burley @ 1998-06-29 20:41 UTC (permalink / raw) To: pcg; +Cc: egcs >On Thu, Jun 25, 1998 at 12:15:17PM -0400, Craig Burley wrote: >> >The original patch turned on -mstack-align-double, which I thought is safe, >> >but it isn't. I got a report from a windows user that it breaks most windows >> >function semantics, as these functions deallocate the stack themselves. In >> >this case, -mstack-align-double will break the program. >> >> Wait, how can these functions deallocate the stack themselves when >> the *caller* also is deallocating the stack, as is normally the > >it isn't: __attribute__((stdcall)). So you are saying gcc knows when it calls a function that the function will do the deallocating? (I'm not sure I fully understand your response, since you didn't explain it particularly carefully. Is that attribute on a function definition or declaration, for example?) In that case, why isn't it simply a bug that -mstack-align-double isn't handling that attribute correctly, and a (fairly) easily fixable bug at that? >> case for x86-ABI code? Aren't these functions essentially violating >> the ABI in a way the compiler producing code that calls them *must* >> know about? > >the problem is we can't change the windows kernel. its a third-party >product I'd really like to recompile ;) I meant what apparently you said about attribute(stdcall) or whatever -- that, if gcc compiles code that calls a non-ABI- obeying function, it *must* be told about that. In other words, there's really no reason -mstack-align-double should have any problems vis-a-vis ABI conformance. If it does, that's just a bug that needs fixing. E.g. for a function with the attribute saying "this is a Windows function that breaks the ABI", it simply doesn't attempt to aligning the outgoing stack frame, or, upon returning, it pseudo-pops the pseudo-pushed 32-bit word. >> >- document that -mno-stack-align-double should be used when linking against third-party-libs >> >- not making it on by default. >> >> If it's not on by default, it's of only limited benefit, though that'd >> still take care of lots of Fortran users who are willing to learn about >> and use an option like -mstack-align-double. > >I had this on by default for half a year in pgcc (until I was told about >windows having problems). It isn't beneficial for integer programs, and >there are a great many of them around. I'm not happy with the idea >of punishing a whole class of functions. Neither am I. But how much does integer stuff slow down? 2% on average? 5% max? Compare that with double-precision speed-ups, which I've been hearing are on the order of in the tens of percents average, as much as 200 or 300%. I still think it's a bit of a tough call, even given that, but others might well disagree and say it's a clear win for always doing alignment. That's the direction in which I lean as well. >If all third-party libraries (e.g. libc) were compiled with this switch (we >only need to have this on for functions using callbacks), we could leave the >choice up to the individual program. Ideally, we'd just leave it up to link-time optimizations, which are (nearly) ideal for properly handling this sort of thing. (Of course, that assumes object files don't contain such nailed-down assembly code.) But that's a *huge* project, and in the meantime, we're getting killed by compilers that do the right thing without needing all sorts of special options, from what I hear. (Can anyone confirm this?) >The problem is mostly speed loss. How much? Especially, how much *peak* loss? IMO, if there are any at-least-moderately-widely-used codes out there that'd suffer more than a 5% slowdown, then this should be taken very seriously, in terms of whether we want to impose that, by default, on users of egcs 1.1. >> But, the problem is that if we don't make -mstack-align-double the >> default, lots of code that uses `double' will not get proper >> alignment and will continue have *big* performance degradation. > >Educate your users. I thought that way for a great long time, maybe I'm >used to tweaking switches, but thats _already_ the case with loop unrolling >or "-O3 vs. -O2". Why isn't loop unrolling on by default? Why Do most >programs use -O2 when -O3 is faster? Gee, thanks. We've spent a couple of years or so already trying to teach them when and how to use -malign-double, and now you're saying we should spend even more time and energy teaching them how and when to use -mstack-align-double (though that's greatly eased by it not breaking the ABI). In the meantime, the "education" misses a huge part of the user base no matter what we do, as we've learned (and expected anyway) over the past several years. Why not just educate *your* users that if they want that last 2 or 3% of performance and they're using no double-precision data, and not calling any procedures (e.g. user-supplied) that might, they should use -mno-stack-align-double? After all, who do you think is more likely to scrutinize the documentation -- people who *really need* that last 2 or 3%, or people who *might* notice (or not, and just explain away as "slow") a 2x or 3x drop in performance compared to *other* x86 compilers out there? In particular, if they *don't* notice a 2-3% slowdown, then they don't care; if they *do*, they'll probably know to read the docs. But users of gcc have hardly ever seen even adequate double-precision performance (unless they happened to use one or two now-obsolete versions of g77, with the dangerous stack-alignment patch), so they are less likely to think the compiler has "gotten" slower, more likely to think it just "is" slow. AFAIK, nobody has ever claimed g77 is "slow" compared to other compilers because it produces code that is 2-3% slower than a competitor. But they often do when that drop is greater than 10%, and too often without reading the docs to see how they might get better performance. Apparently that's because other vendors often make the "right" choices about numerical performance (though it'd be worthwhile to research just how some x86 Fortran vendors handle the 64-bit-alignment problem vis-a-vis "alien" code), so users of those vendors' compilers don't have to study long lists of possibly useful options to get remotely in the ballpark of decent performance. And apparently many users doing benchmarks consider that a quality issue -- how good performance is using *vanilla* options like -O, without having to read tons of docs (especially in the case of gcc/g77, which, as portable products, have tons of machine-specific optimization options). Whereas, that seems to be what you're asking gcc/g77/g++/GNAT users to do -- to get double-precision performance that's even within 2x or 3x of performance (even with *moderate* optimization), they have to learn about and compile with -mstack-align-double throughout their program. That's not even a portable option (across machines gcc supports). As far as why loop unrolling and other things are the way they are, there's a variety of reasons. One is that sometimes the code is considered insufficiently tested to enable for the default optimization level (-O1). Another is that it can greatly inflate some types of code and/or data structures. Another is that it can greatly increase the amount of time the compiler takes to compile some types of code. Another is that it can actually slow down certain types of code, sometimes greatly, maybe even *most* types of code. Without having info on how much slower integer codes really get, I'm assuming the only pertinent reason that applies to making -mstack-align-double the default is the first -- that the code is insufficiently tested. However, that's mitigated by the fact that this isn't an optimization "pass" in the usual sense -- in fact, it's got to be used *widely* to even begin to see any benefits from it, so if it isn't enabled by default, IMO it probably won't get used by more than 1% of the entire user base. Hence, it won't be tested, and gcc will continue to appear to be a poor performer. (Most people who'd use it will just use -malign-double to get "all" the performance, is my guess.) In fact, without having certain important libraries compiled with this option enabled by default, the *entire* exercise is pointless for about 99% of the users who *would* see big performance improvements if we made it the default. That's why, IMO, -mstack-align-double should be the default *period*, including for unoptimized code (-O0). I'd love to see gcc taught to effectively avoid doing this stuff in cases where it's clear no double-precision arithmetic is involved, though. E.g. leaf functions with no DP vars, and functions that have no DP vars and call only leaf functions of that sort or of their own sort. That might restore much of the apparent lossage from making -mstack-align-double the default. Another approach is to make -mno-stack-align-double the default and teach gcc to special-case any function *not* meeting the above requirements (e.g. functions with DP vars, or that might call those with them) by somehow forcibly aligning the incoming stack frame (if local DP vars exist). That'd require conditionally moving the incoming args collectively by 4 bytes (if the frame is unaligned), and dealing with the fallout of this (it might affect profiling, exceptions, debugging, etc.). But either of the above approaches is going to take quite a bit more time, well beyond the 1.1 timeframe. So the question for 1.1 is: assuming we *can* make -mstack-align-double the default (and my quick tests of it didn't seem too promising, but then I realized some of that might be due to the g77 bugs I think I've finally found and fixed as of a couple of hours ago), *should* we for 1.1? Should we default to as much as 300% speedups in double-precision code and as much as 2-5% (?) slowdowns in non-DP code, or continue "straining" to get the last few percentages points for non-DP code at the *huge* (and embarrassing) expense of DP code? tq vm, (burley) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-29 20:41 ` Craig Burley @ 1998-06-30 0:42 ` Jeffrey A Law 1998-06-30 8:19 ` gcc2 merge H.J. Lu 0 siblings, 1 reply; 47+ messages in thread From: Jeffrey A Law @ 1998-06-30 0:42 UTC (permalink / raw) To: Craig Burley; +Cc: pcg, egcs > So the question for 1.1 is: assuming we *can* make -mstack-align-double > the default (and my quick tests of it didn't seem too promising, > but then I realized some of that might be due to the g77 bugs I > think I've finally found and fixed as of a couple of hours ago), > *should* we for 1.1? Should we default to as much as 300% speedups > in double-precision code and as much as 2-5% (?) slowdowns in > non-DP code, or continue "straining" to get the last few percentages > points for non-DP code at the *huge* (and embarrassing) expense of > DP code? I think we need to answer this question once we've got some code to get the stack and VAR_DECLs aligned properly so that we can measure the benefit on some code *and* measure the loss on integer code. We all have gut feelings about what we're going to find, but it would really be to our advantage to get some hard data. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* gcc2 merge 1998-06-30 0:42 ` Jeffrey A Law @ 1998-06-30 8:19 ` H.J. Lu 1998-06-30 19:49 ` Jeffrey A Law 0 siblings, 1 reply; 47+ messages in thread From: H.J. Lu @ 1998-06-30 8:19 UTC (permalink / raw) To: law; +Cc: egcs There is a new gcc2 snapshot. Should we take a look to see if there are any bug fixes? H.J. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: gcc2 merge 1998-06-30 8:19 ` gcc2 merge H.J. Lu @ 1998-06-30 19:49 ` Jeffrey A Law 0 siblings, 0 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-30 19:49 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs In message <m0yr2BR-000266C@ocean.lucon.org>you write: > There is a new gcc2 snapshot. Should we take a look to see if there > are any bug fixes? I thought about just importing/merging it since it's only 2 weeks of low volume changes. Too bad it was made right after I had 90% of the merge from 980609 done :( jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: x86 double alignment (was egcs-1.1 release schedule) 1998-06-28 22:41 ` Marc Lehmann 1998-06-29 5:20 ` Martin Kahlert 1998-06-29 20:41 ` Craig Burley @ 1998-06-30 4:50 ` Jeffrey A Law 2 siblings, 0 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-30 4:50 UTC (permalink / raw) To: Marc Lehmann; +Cc: egcs In message < 19980628214914.40045@cerebro.laendle >you write: > I had this on by default for half a year in pgcc (until I was told about > windows having problems). It isn't beneficial for integer programs, and > there are a great many of them around. I'm not happy with the idea > of punishing a whole class of functions. > > If all third-party libraries (e.g. libc) were compiled with this switch (we > only need to have this on for functions using callbacks), we could leave the > choice up to the individual program. I'm not particularly happy with it either, but sometimes that's the tradeoff we have to make. What we have to do is quantify the integer slowdowns and the floating point speedups and make a value decision about which is more important. This is a common thing to have to do when optimizing code -- few things are always going to be a win. So you have to evaluate how often they win vs how often they lose -- you do this both with benchmarks and instinct. The other thing to do is look for cases where you can mitigate the losses. The example that has come up is leaf functions. I must admit that I'm curious how much slowdown we're going to see for integer code. I'd expect it to be rather small, but I must admit that I don't really know for sure. > Educate your users. I thought that way for a great long time, maybe I'm > used to tweaking switches, but thats _already_ the case with loop unrolling > or "-O3 vs. -O2". Why isn't loop unrolling on by default? Why Do most > programs use -O2 when -O3 is faster? That's fine for a hacker community. That doesn't work for a the larger developer community. Loop unrolling is very much a hit or miss proposition. It's just as likely to make things worse as it is to make them better. -O3 can make code run slower, it can make the compiler run slower, it makes debugging even harder. It can also make things run faster, it really depends on the code. jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* egcs-1.1 release schedule 1998-06-18 1:32 egcs-1.1 release schedule Jeffrey A Law 1998-06-19 9:02 ` Gerald Pfeifer 1998-06-19 11:57 ` Dave Love @ 1998-06-20 6:41 ` Gabriel Dos Reis 1998-06-20 9:22 ` Joe Buck 1998-06-21 0:07 ` Jeffrey A Law 2 siblings, 2 replies; 47+ messages in thread From: Gabriel Dos Reis @ 1998-06-20 6:41 UTC (permalink / raw) To: egcs Is there any project to improve alias analysis (C++) and const reference optimization to be included in egcs-1.1 ? -- Gaby "Abstraction is selective ignorance." -- Andrew Koenig ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-20 6:41 ` egcs-1.1 release schedule Gabriel Dos Reis @ 1998-06-20 9:22 ` Joe Buck 1998-06-20 15:36 ` Mark Mitchell 1998-06-21 0:07 ` Jeffrey A Law 1 sibling, 1 reply; 47+ messages in thread From: Joe Buck @ 1998-06-20 9:22 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: egcs > Is there any project to improve alias analysis (C++) and const > reference optimization to be included in egcs-1.1 ? egcs-1.1 is unlikely to contain anything that isn't in the current snapshot (except for simple bug fixes). It will have ADDRESSOF, which can improve some simple cases (passing a struct or class with one field by const reference to an inlined function, for example). ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-20 9:22 ` Joe Buck @ 1998-06-20 15:36 ` Mark Mitchell 0 siblings, 0 replies; 47+ messages in thread From: Mark Mitchell @ 1998-06-20 15:36 UTC (permalink / raw) To: jbuck; +Cc: Gabriel.Dos-Reis, egcs >>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes: >> Is there any project to improve alias analysis (C++) and const >> reference optimization to be included in egcs-1.1 ? Joe> egcs-1.1 is unlikely to contain anything that isn't in the Joe> current snapshot (except for simple bug fixes). It will have Well, I did submit code to type-based alias analysis about a week ago. I'm hoping that code will be in the 1.1. release; that will depend on a) Jeff's availability to look at the code and b) whether he thinks I did a good job or not. This code makes a huge difference on some scientific computing benchmarks one of my customers is using. You can look through the egcs-patches archive if you're interested in trying out the patch. -- Mark Mitchell mark@markmitchell.com Mark Mitchell Consulting http://www.markmitchell.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: egcs-1.1 release schedule 1998-06-20 6:41 ` egcs-1.1 release schedule Gabriel Dos Reis 1998-06-20 9:22 ` Joe Buck @ 1998-06-21 0:07 ` Jeffrey A Law 1 sibling, 0 replies; 47+ messages in thread From: Jeffrey A Law @ 1998-06-21 0:07 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: egcs In message < 199806201335.PAA13904@piano.dptmaths.ens-cachan.fr >you write: > > > Is there any project to improve alias analysis (C++) and const > reference optimization to be included in egcs-1.1 ? Interestingly enough Mark Mitchell posted some code to improve alias analysis very recently. I haven't had a chance to look at it yet. It would also be helpful if John Carr could take a looksie since he owns our current backend alias code. :-) jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~1998-06-30 19:49 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-06-18 1:32 egcs-1.1 release schedule Jeffrey A Law 1998-06-19 9:02 ` Gerald Pfeifer 1998-06-19 23:47 ` Jeffrey A Law 1998-06-19 11:57 ` Dave Love 1998-06-21 21:43 ` Craig Burley 1998-06-21 23:07 ` Jeffrey A Law 1998-06-22 5:19 ` David S. Miller 1998-06-22 12:04 ` Dave Love 1998-06-22 13:45 ` Toon Moene 1998-06-22 22:29 ` Jeffrey A Law 1998-06-22 18:20 ` ix86 double alignment (was Re: egcs-1.1 release schedule) Craig Burley 1998-06-23 3:32 ` David S. Miller 1998-06-23 6:30 ` Craig Burley 1998-06-23 3:32 ` Jeffrey A Law 1998-06-23 5:13 ` Craig Burley 1998-06-22 12:04 ` ix86 `double' " Craig Burley 1998-06-23 3:32 ` Jeffrey A Law 1998-06-23 5:13 ` Craig Burley 1998-06-24 2:28 ` Jeffrey A Law 1998-06-24 14:50 ` Craig Burley 1998-06-25 0:25 ` Jeffrey A Law 1998-06-25 9:59 ` Tim Hollebeek 1998-06-28 18:01 ` Marc Lehmann 1998-06-22 12:04 ` egcs-1.1 release schedule Dave Love 1998-06-23 3:32 ` Craig Burley 1998-06-23 3:32 ` Jeffrey A Law 1998-06-23 9:29 ` H.J. Lu 1998-06-24 17:12 ` x86 double alignment (was egcs-1.1 release schedule) Marc Lehmann 1998-06-25 0:25 ` Jeffrey A Law 1998-06-28 18:02 ` Marc Lehmann 1998-06-25 12:33 ` PÃ¥l-Kristian Engstad 1998-06-28 18:02 ` Marc Lehmann 1998-06-25 21:48 ` Craig Burley 1998-06-25 18:53 ` Jeffrey A Law 1998-06-28 22:41 ` Marc Lehmann 1998-06-29 5:20 ` Martin Kahlert 1998-06-29 11:08 ` Jeffrey A Law 1998-06-29 19:43 ` Craig Burley 1998-06-29 20:41 ` Craig Burley 1998-06-30 0:42 ` Jeffrey A Law 1998-06-30 8:19 ` gcc2 merge H.J. Lu 1998-06-30 19:49 ` Jeffrey A Law 1998-06-30 4:50 ` x86 double alignment (was egcs-1.1 release schedule) Jeffrey A Law 1998-06-20 6:41 ` egcs-1.1 release schedule Gabriel Dos Reis 1998-06-20 9:22 ` Joe Buck 1998-06-20 15:36 ` Mark Mitchell 1998-06-21 0:07 ` Jeffrey A Law
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).