From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28335 invoked by alias); 8 Feb 2011 14:25:19 -0000 Received: (qmail 28322 invoked by uid 22791); 8 Feb 2011 14:25:18 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,TW_CP,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Feb 2011 14:25:13 +0000 Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p18EPBOd003422 for ; Tue, 8 Feb 2011 06:25:11 -0800 Received: from pwi5 (pwi5.prod.google.com [10.241.219.5]) by hpaq1.eem.corp.google.com with ESMTP id p18EP6Jl002735 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 8 Feb 2011 06:25:10 -0800 Received: by pwi5 with SMTP id 5so4095689pwi.25 for ; Tue, 08 Feb 2011 06:25:06 -0800 (PST) Received: by 10.143.161.6 with SMTP id n6mr1374554wfo.151.1297175106131; Tue, 08 Feb 2011 06:25:06 -0800 (PST) Received: from coign.google.com ([216.239.45.130]) by mx.google.com with ESMTPS id x18sm7644867wfa.11.2011.02.08.06.25.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 06:25:05 -0800 (PST) From: Ian Lance Taylor To: David Brown Cc: gcc-help@gcc.gnu.org Subject: Re: suggestion for GCC (1) References: <4D50848C.1070900@student.htw-berlin.de> Date: Wed, 09 Feb 2011 04:54:00 -0000 In-Reply-To: (David Brown's message of "Tue, 08 Feb 2011 11:37:35 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-02/txt/msg00158.txt.bz2 David Brown writes: >> Of course we could still arrange to provide simple versions in some >> additional library which is only linked after libc. I would not be >> opposed to that. Real C programs, though, almost always call memcpy and >> friends themselves, and real C programs always require some level of >> supporting code. The current situation doesn't really bother me. >> > > Doesn't gcc treat functions like memcpy as builtins? Or is that only > if you explicitly write __builtin__memcpy? I would have thought that > in many cases, a builtin version can be a lot smaller and faster than > library code, since the compiler often knows about things like > alignment and sizes and can thus generate better code. The compiler does by default treat functions like memcpy as builtins, and it's true that when the compiler does know something about alignment and sizes it can sometimes generate better code. However, there are many cases where the compiler does not know anything about the alignment or size, and then the compiler can't do any better than the library routine. Ian