From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23726 invoked by alias); 15 Sep 2014 11:21:44 -0000 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 Received: (qmail 23674 invoked by uid 89); 15 Sep 2014 11:21:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 15 Sep 2014 11:21:41 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8FBLddE012063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 15 Sep 2014 07:21:40 -0400 Received: from zebedee.pink ([10.3.113.10]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8FBLcj2022457; Mon, 15 Sep 2014 07:21:38 -0400 Message-ID: <5416CBC1.50900@redhat.com> Date: Mon, 15 Sep 2014 11:21:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: Hei Chan , "gcc-help@gcc.gnu.org" Subject: Re: is portable aliasing possible in C++? References: <1410390231.39617.YahooMailNeo@web140202.mail.bf1.yahoo.com> <54115917.1040602@redhat.com> <1410477938.56522.YahooMailNeo@web140205.mail.bf1.yahoo.com> <5412AF85.1080200@redhat.com> <1410562688.66898.YahooMailNeo@web140201.mail.bf1.yahoo.com> <5413F0D4.5010806@redhat.com> <1410748615.48628.YahooMailNeo@web165004.mail.bf1.yahoo.com> <5416A4E1.1010000@redhat.com> <1410779226.12412.YahooMailNeo@web165006.mail.bf1.yahoo.com> In-Reply-To: <1410779226.12412.YahooMailNeo@web165006.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00084.txt.bz2 On 09/15/2014 12:07 PM, Hei Chan wrote: > >> On Monday, September 15, 2014 4:36 PM, Andrew Haley wrote: >> On 15/09/14 03:36, Hei Chan wrote: >>> >>> This is an interesting thread. >>> >>> I think it is very common that people try to avoid making a copy >>> from the buffer filled by recv() (or alike) to achieve lowest >>> latency. >>> >>> Given that >>> 1. The "union trick" has always worked with GCC, and is now hallowed >>> by the standard. So it sounds like GCC might change in the future. >> >> Why? > > Your statement that the trick "is now hallowed by the standard" > makes it sounds like at some point GCC won't guarantee it work > anymore. I disagree. It does not say that. GCC will not change this behaviour. >>> 2. Somewhere in the code that might manipulate the buffer via >>> somehow casted packed C struct. Hence, any compiler is unlikely >>> able to avoid making call if memcpy() is used. >> >> I don't understand what you mean by this. You can always write a >> function which takes a pointer to a character type and calls memcpy() >> to copy it into any scalar type, and it won't unnecessarily call >> anything; or if it does that's a missed-optimization bug. > > > Sorry, it is a typo -- I mean "compiler is unlikely able to avoid > making *a copy* if memcpy() is used". The compiler is likely to be able to avoid making a copy if memcpy() is used. > Using the unsafe reinterpret_cast (C fashion cast), it won't have an > extra copy. The alignment requirement is a property of the hardware. It is not a property of the software. If the type needs aligning, it'll have to be aligned somehow. Using reinterpret_cast does not help. > Using memcpy(), the compiler will have to make a copy > because it sees that few lines, for example, down, the program tries > to manipulate the copy. So, don't manipulate the copy, then. Use it once, then throw it away. >>> Then, I have the following questions: >>> A. I use GCC and portability isn't an issue. What is the best type >>> punning method to achieve lowest latency? > >> A union. You need a union to guarantee alignment. > > So I guess there is no way to avoid a copy if the code manipulates > the member of the union, right? There is no need for a copy. I already produced an example which proves that. > I understand that union and memcpy() would guarantee alignment. I > was just hoping that there is a way of guaranteeing alignment > without an extra copy. Sounds like there is no way? It depends on the processor; on x86 and some ARMs and others yes. On some others no. Andrew.