From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67534 invoked by alias); 5 Aug 2016 17:48:24 -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 67513 invoked by uid 89); 5 Aug 2016 17:48:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f49.google.com Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 05 Aug 2016 17:48:21 +0000 Received: by mail-wm0-f49.google.com with SMTP id f65so39949721wmi.0 for ; Fri, 05 Aug 2016 10:48:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:from:date:to:cc:message-id; bh=RjmhxejqJ0DbaqOacWjeMTa6UDgXEvpoabVNym3im0I=; b=d5gsrZcgZVjqUTAmT2n/sefXDNy96yRxUl8Q5AjmEnXTP5oFrfPw7CkfCxMK08kTLx O2hbK6SBz51HHzNYPMfl571jVbtQBl208Otl6MjHWSt8TSt24dbRAkHTCe8sV6zo12pl 624FC8pjSGE5jA5vPn/bzt8FoE9MFcRMiuoiOgJvuv7ocYzdfWQDn3dehJXJ1OWOxjGF fgChGp8olRvYYiYP3h5GO4832gm1Lo8Re/XBqlJMnLbfCIHP4Y1OMgRk6hkAw1zL2OGa VotTaDyf/KYU9z79Rvd8B4lGjwpoZP9SKWDnFUDEM8JUj/LAKlE6OK2heTWi7sNPKLlD V7nQ== X-Gm-Message-State: AEkooutX+x2HzCxJnmL2TZh1/HrjIzY2kjK1iy+03SSe5SvUG1AhJsb+A8JtVG0n02Ab5w== X-Received: by 10.194.54.37 with SMTP id g5mr80536380wjp.65.1470419298637; Fri, 05 Aug 2016 10:48:18 -0700 (PDT) Received: from 192-168-178-29.fritz.box (p5DC9A447.dip0.t-ipconnect.de. [93.201.164.71]) by smtp.gmail.com with ESMTPSA id 17sm9668672wmf.6.2016.08.05.10.48.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 10:48:17 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <082fc386-345c-efa1-e1cd-053b1aa989a3@redhat.com> References: <57A32741.7010003@redhat.com> <57A35CF6.1040504@redhat.com> <87147ff6-0133-0ba7-17ae-980fe425bf57@redhat.com> <57A4A4B9.9090908@redhat.com> <082fc386-345c-efa1-e1cd-053b1aa989a3@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: protected alloca class for malloc fallback From: Richard Biener Date: Fri, 05 Aug 2016 17:48:00 -0000 To: Jeff Law ,Aldy Hernandez CC: gcc-patches ,Pedro Alves Message-ID: <055B4606-06E0-4351-8C40-A37C7F259C0A@gmail.com> X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00484.txt.bz2 On August 5, 2016 6:23:27 PM GMT+02:00, Jeff Law wrote: >On 08/05/2016 08:37 AM, Aldy Hernandez wrote: >> >> After looking at all this code, I realize no size will fit all if we >> want something clean. So, I take my approach back. I think we're >best >> served by a couple different approaches, depending on usage. >Yup. > >> >> My question is, how wed are we to an alloca based approach? Can we >> replace the non-critical uses by std::string (diagnostics, >> BLAH_check_failed(), building a string to manipulate the output of >> env("SOME_VAR"), etc?). >I don't think we are at all wed to alloca. > >> >> Then for things like the GCC driver wanting to create a vector of >passed >> commands, we could use auto_vec<> (*gasp*, using a vector to >represent a >> vector ;-)). Note that auto_vec<> uses malloc (or GC) but creating a >> malloc'd vector at startup is hardly on the fast path. >> >> For the remaining things we could use either alloca with a malloc >> fallback for trivial things like set_user_assembler_name() that only >> have one exit point, or take it on a case by case basis. >> >> But it seems to me that we can use an STL container for the non >critical >> things (which are the majority of them), and something else (perhaps >an >> RAII thinggie TBD later). >> >> Is this reasonable? I'd like to know before I spend any time >converting >> anything to std::string and auto_vec<>. >Yes, this is all reasonable to me. I'm a big believer in moving >towards >standard library implementations of things. In this case we get to >remove the allocas *and* make the code easier to grok for those that >are >familiar with the C++ standard library. But at the same time please consider that each malloc costs 1000x more than an alloca. So if you replace one alloca that is executed once during compile, fine. If you replace one that is done for each symbol (the get_identifier case) it is not. Richard. >Jeff