In that case I think it’s even more useful to have the first comma, as it helps differentiate the varying uses of the two “and”s in the sentence (the first being a list-item-separator and the second a simple-conjunction) which otherwise would naturally be read as having the same function. --paulr
From: [email protected] [mailto:[email protected]] On Behalf Of Richard Smith Sent: Wednesday, April 23, 2014 11:34 AM To: Robinson, Paul Cc: Diego Novillo; [email protected] Subject: Re: r206995 - Review feedback On Wed, Apr 23, 2014 at 11:22 AM, Robinson, Paul <[email protected]<mailto:[email protected]>> wrote: > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto:cfe-commits-<mailto:cfe-commits-> > [email protected]<mailto:[email protected]>] On Behalf Of Diego Novillo > Sent: Wednesday, April 23, 2014 8:21 AM > To: [email protected]<mailto:[email protected]> > Subject: r206995 - Review feedback ... > In particular, sample profilers can provide execution counts for all > -instructions in the code, information on branches taken and function > +instructions in the code and information on branches taken and function This reads better with the comma. (It's debatable whether there should be a second comma before "and function" (the interminable "serial comma" debate)). I'm indifferent on putting a comma before the first 'and'. There should definitely not be a second comma. This is intended to parse as: In particular, sample profilers can provide * execution counts for all instructions in the code and * information on branches taken and function invocation. Adding a comma before each 'and' would lead this to parse as In particular, sample profilers can provide * execution counts for all instructions in the code, and * information on branches taken, and * function invocation. ... which is not what was intended. --paulr > invocation. The compiler can use this information in its optimization > cost models. For example, knowing that a branch is taken very > frequently helps the compiler make better decisions when ordering > basic blocks. Knowing that a function ``foo`` is called more > -frequently than another ``bar`` helps the inliner. > +frequently than another function ``bar`` helps the inliner. _______________________________________________ cfe-commits mailing list [email protected]<mailto:[email protected]> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
