Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!ncifcrf!lhc!nih-csl!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: C compilers code generation Message-ID: Date: 17 Nov 90 19:06:49 GMT References: <1990Nov12.135444.10739@cs.utwente.nl> Lines: 38 In article cedman@golem.ps.uci.edu (Carl Edman) writes: > >That e.g. memmove() functions which are really optimal are quite large >might be true. But most of that complexity results from an analysis >of the parameters and choosing the corresponding algorithm to deal >... >make up most of the code. But now imagine a C compiler which does >the parameter analysis (as far as possible) at run time and only >inserts the 'correct' routine for these parameter sets. > >I think you will have to admit that in this case you could have significant >speedups and space savings. > > Carl Edman -- Uh huh, right. movmem(s, d, len) Now, unless all the parameters are basically globals of known alignment AND the 'length' is a constant, the compiler will not be able to make any major assumptions about the copy. Basically, a movmem would have to use the same operational guidelines as a structural assignment for the compiler to be able to make any assumptions, and then you might as well use a structure / structure assignment rather than a movmem. Unless you can find several optimizable examples that would be *WIDELY* used in random source code (at least as a percentage of movmem()s in the source code), my opinion will not change :-) -Matt Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA