From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Henderson Subject: Re: strcmp is too heavy for its everyday usage... Date: Fri, 9 Jan 2004 00:12:31 -0800 Sender: libc-alpha-owner@sources.redhat.com Message-ID: <20040109081231.GA4218@twiddle.net> References: <20040108060924.A4431@zzz.ward.six> <200401080113.i081DB1c000920@magilla.sf.frob.com> <20040108063636.C11508@zzz.ward.six> <20040109101145.A8801@zzz.ward.six> Mime-Version: 1.0 Return-path: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Content-Disposition: inline In-Reply-To: <20040109101145.A8801@zzz.ward.six> List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andreas Schwab , Roland McGrath , Zack Weinberg , Andreas Jaeger , Richard Henderson , libc-alpha@sources.redhat.com, linux-gcc@vger.kernel.org On Fri, Jan 09, 2004 at 10:11:45AM +0500, Denis Zaitsev wrote: > (r= a[0] - b[0]) && > (r= a[1] - b[1]) && > (r= a[2] - b[2]) && > (r= a[3] - b[3]); > return r; > } > > It's a typical inline code for compare 4-byte of mem. When it is > used, say, in such a context > > s(a,b) ? A() : B(); > > GCC discards the value of r perfectly, leaving the only code needed > for compare bytes for eq/neq. But GCC doesn't merge the 4 byte > comparing into single word comparing. And, as I understand, it will > never do that, as it's not asked to. Or this kind of optimization is > assumed ok for compiler, but just still unimplemented? Certainly it's ok if it converts. However, on most targets you'd have to know that a and b are aligned. Worse, even for targets like x86 that support unaligned loads you have to know for certain that neither a[3] nor b[3] could possibly segv when a[0] and b[0] won't. That condition is trivial when a and b are aligned, but otherwise... Adding compensation code to deal with the extra conditions that must be satisfied will probably negate whatever you're hoping to gain here. r~