Re: Separate commit mailing lists for trunk/branches possible?
On Fri, 17 Jul 2020, Christopher Faylor wrote: > > Most of this stuff is vendor branch stuff I find completely uninteresting > >to me and which from my point of view is a waste of resources. I could > >filter it to /dev/null via `procmail', but that would still be a waste. > > Actually, it seems like a procmail rule would solve your problem. Not the issue of wasted resources including the list server processing and sending the messages intended to my address, bandwidth and all the network equipment involved on the way, and finally the local mail server receiving and dispatching the message to `procmail'. It all does not come for free. Maciej
Re: Separate commit mailing lists for trunk/branches possible?
Hi - > Not the issue of wasted resources including the list server processing > and sending the messages intended to my address, bandwidth and all the > network equipment involved on the way, and finally the local mail server > receiving and dispatching the message to `procmail'. It all does not come > for free. FWIW, I'd estimate the incremental infrastructure cost of sending these messages, over not sending these messages, at pretty close to zero. The most valuable part is human attention time, which could make it worthwhile to reduce spamminess. - FChE
Re: Separate commit mailing lists for trunk/branches possible?
On Sun, 19 Jul 2020, Frank Ch. Eigler wrote: > > Not the issue of wasted resources including the list server processing > > and sending the messages intended to my address, bandwidth and all the > > network equipment involved on the way, and finally the local mail server > > receiving and dispatching the message to `procmail'. It all does not come > > for free. > > FWIW, I'd estimate the incremental infrastructure cost of sending > these messages, over not sending these messages, at pretty close to > zero. The most valuable part is human attention time, which could > make it worthwhile to reduce spamminess. Maybe it's me tilting at windmills, but waste accumulates. If everyone ignores a small waste of resources, then eventually they'll run out. And I'm not sure if it's human attention time or the environment that is most valuable, and all the resources we use for networking have environmental impact. Time is already wasted every day on even less important issues, some of which caused by other people actually not paying enough attention. FWIW, Maciej
gcc-11-20200719 is now available
Snapshot gcc-11-20200719 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20200719/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 2e1b25350aa96b3f5678a056d0b55bb323c452d9 You'll find: gcc-11-20200719.tar.xz Complete GCC SHA256=68375e9b63787c475af1a521498519e155ca8b5ff8b3752c58909e9c460c5a0f SHA1=4fea837c6b9795508902437c9a9838cc7f65e1c5 Diffs from 11-20200712 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
How to ignore the vector's duplication
Hi everyone, As we know, before we add a vector and a scalar, the first thing to do is to duplicate the scalar varable. For example (the vector has a length of 16): for (int i = 0; i < 16; i ++) c[i] = a[i] + b; will goes to: vld v0,a0 vdup v1,a1 vadd v0,v0,v1 vfst v0,a2 And now we can deal with the addtion of a vector and a scalar directly by "vadds", so the assembler above could be optimized like: vld v0,a0 vadds v0,v0,a1 vfst v0,a2 we can achieve this goal by peephole for the loop size 16, but if we enlarge the loop size to 32, the peephole will be missed like: vld v0,a0 vdup v1,a1 vadd v0,v0,v1 addi a3,a0,32 addi a4,a2,32 vfst v0,a2 vld v2,a3 vadd v0,v2,v1 vfst v0,a4 Is there any way to let GCC ignore the vector's duplication no matter the size of loop, for using the "vadds" only?
