From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99647 invoked by alias); 8 Aug 2016 17:32:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 99635 invoked by uid 89); 8 Aug 2016 17:32:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=string_view, trade, our X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Aug 2016 17:32:15 +0000 Received: from ball (unknown [IPv6:2607:f0c8:8000:80e0:56ee:75ff:fe52:afb9]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id BAC88C0A4; Mon, 8 Aug 2016 17:32:13 +0000 (UTC) Date: Mon, 08 Aug 2016 17:32:00 -0000 From: Trevor Saunders To: Jeff Law Cc: Richard Biener , Aldy Hernandez , Oleg Endo , Martin Sebor , gcc-patches Subject: Re: protected alloca class for malloc fallback Message-ID: <20160808173939.GA13790@ball> References: <57A32741.7010003@redhat.com> <57A3F57F.3050509@gmail.com> <57A4A5E8.90205@redhat.com> <1470420954.639.64.camel@t-online.de> <44EE0FB0-A8B9-43F9-BF58-C4D7D27DA944@gmail.com> <57A5B8BE.2000004@redhat.com> <941D179C-146F-4004-BECB-9FB066DDCC8D@gmail.com> <21bcbebe-28a8-58a7-68e8-af9abcb03dce@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21bcbebe-28a8-58a7-68e8-af9abcb03dce@redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) X-SW-Source: 2016-08/txt/msg00617.txt.bz2 On Mon, Aug 08, 2016 at 11:00:28AM -0600, Jeff Law wrote: > On 08/06/2016 09:08 AM, Richard Biener wrote: > > On August 6, 2016 12:15:26 PM GMT+02:00, Aldy Hernandez wrote: > > > On 08/05/2016 04:07 PM, Richard Biener wrote: > > > > On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo > > > wrote: > > > > > On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote: > > > > > > > > > > > > > > > > > Please don't use std::string. For string building you can use > > > > > > obstacks. > > > > > > > > > > > > > > > > Just out of curiosity ... why? I remember there was some discussion > > > > > about it, what was the conclusion? Is that now a general rule or > > > does > > > > > it depend on the context where strings are used? > > > > > > > > Because you make a messy mix of string handling variants. > > > Std::string is not powerful enough to capture all uses, it is vastly > > > more expensive to embed into structs and it pulls in too much headers. > > > > (Oh, and I hate I/o streams even more) > > > > > > Oh, and there is prior use in ipa-chkp.c, although I suppose it > > > could've > > > crept in: > > > > Definitely. > > > > > > > > std::string s; > > > > > > /* called_as_built_in checks DECL_NAME to identify calls to > > > builtins. We want instrumented calls to builtins to be > > > recognized by called_as_built_in. Therefore use original > > > DECL_NAME for cloning with no prefixes. */ > > > s = IDENTIFIER_POINTER (DECL_NAME (fndecl)); > > > s += ".chkp"; > > > DECL_NAME (new_decl) = get_identifier (s.c_str ()); > > > > > > You can't tell me obstacks are easier on the eyes for this ;-). > > > > Even strcat is shorter and cheaper. > ISTM that unless the code is performance critical we should be writing code > that is easy to understand and hard to get wrong. it seems hard to disagree with that ;) > Thus when we have something that is non-critical and can be handled by std:: > routines we should be using them. > > If performance is important in a particular piece of code an obstack or > explicit malloc/free seems better. I'm not totally convinced we have to trade off performance against a good interface. It seems to me it wouldn't be that complicated to build a string class on top of auto_vec that has a similar interface to std::string. I'd really rather not have to write a string class of our own, but I can see some significant advantages to it. First sizeof std::string is 32 on x86_64, a char *, a size_t for the length, and a 16 byte union of a size_t for allocated size and a 16 byte buffer for short strings. I suppose some of this is required by the C++ standard, but I doubt we really need to care about strings longer than 2^32 in gcc. If we put the length and allocated size in the buffer, and have a separate class for stack allocated buffers I think we can have a string that is just sizeof void *. Second it would be useful performance wise to have a std::string_view type class, but that is c++14 or 17? only so we'd need to import it into gcc or something. Trev