From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98342 invoked by alias); 19 Oct 2016 03:31:13 -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 95792 invoked by uid 89); 19 Oct 2016 03:30:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hoping, udivmod, standpoint, mine X-HELO: mail-it0-f54.google.com Received: from mail-it0-f54.google.com (HELO mail-it0-f54.google.com) (209.85.214.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Oct 2016 03:30:45 +0000 Received: by mail-it0-f54.google.com with SMTP id 4so100891707itv.0 for ; Tue, 18 Oct 2016 20:30:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mWl8Uix2Mu0N4ZLhRKfLyf/5TGzYhGogcY/M5nreFI4=; b=gWrvaAlHVrnHozejR0mVzp5Wsne5wIyD/r+VxT2vKvoFKzs3zxWgEQoIu4L7JTe8zI 8Yuec8t5TvcnjGT/zBpep6I8AYWsH2VXTjACJRg/rw1SomPMbXANeyERxvabXLNGG6/n Kj2AbwC4TvChs4grCJs1YSRGZMFPFp4fY6vo8U709UDGVIdP62fT8H7G13/R8UARES8i 9xQc3BWmIC7jhL1xIn4fR48Uz9sDSKoV2OFlelwAZVOG7KNFAjrqQ5QOy77JG2lV1bVT 0oqor5MHHhL/csywwLqnt76x8bY9vpCVADBuc3Y5CZRHqk+0Xk3yznS9gfPZoNStQ9TR V31w== X-Gm-Message-State: AA6/9Rl6X2VrokJFmllaCsQp8Z26oB38IFFJMeg33RcPGCU9TyftwqxHHuQIL0I8OxsEHOxWsfslZiKBDYdLC4pF X-Received: by 10.36.73.23 with SMTP id z23mr974639ita.32.1476847827195; Tue, 18 Oct 2016 20:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.112.78 with HTTP; Tue, 18 Oct 2016 20:30:26 -0700 (PDT) In-Reply-To: References: From: Prathamesh Kulkarni Date: Wed, 19 Oct 2016 03:31:00 -0000 Message-ID: Subject: Re: RFC [1/3] divmod transform v2 To: Jeff Law Cc: gcc Patches , Richard Biener , Kugan , Jim Wilson Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg01490.txt.bz2 On 19 October 2016 at 03:03, Jeff Law wrote: > On 10/17/2016 11:23 PM, Prathamesh Kulkarni wrote: >> >> The divmod transform isn't enabled if target supports hardware div in >> the same or wider mode even if divmod libfunc is available for the >> given mode. > > Good. That seems like the right thing to do. > >> Thanks. I had erroneously assumed __udivimoddi4() was available for >> all targets because it was defined in libgcc2.c and generated call to >> it as "last resort" for unsigned DImode case if target didn't support >> hardware div and divmod insn and didn't have target-specific divmod >> libfunc for DImode. The reason why it generated undefined reference >> on aarch64-linux-gnu was because I didn't properly check in the patch >> if target supported hardware div, and ended up generating call to >> __udivmoddi4() even though aarch64 has hardware div. I rectified >> that before posting the patch. > > Understood. From a design standpoint, it seems to me like the path where we > emit a call to udivmod without knowing if its supported by libgcc is broken. > But if I understand correctly, that's not affected by your changes -- it's > simply a historical poor decision. Err no, that poor decision was entirely mine -;) I had wrongly assumed __udivmoddi4 to be always available and got surprised when it gave undefined reference error on aarch64 and hence brought it up for discussion. I removed those parts of the patch that generated call to __udivmoddi4() before posting the patch upstream. > >>> >>> I don't even think we have a way of knowing in the compiler if the >>> target has enabled divmod support in libgcc. >> >> Well the arm and c6x backends register target-specific divmod libfunc >> via set_optab_libfunc(). I suppose that's sufficient to know if >> target has divmod enabled in libgcc ? > > It's probably a pretty reasonable assumption that if the target has > registered a libfunc, the the libfunc ought to be available. > >>> >>> ISTM that for now we have to limit to cases where we have a divmod >>> insn/libcall defined. >> >> Indeed. The transform is enabled only if the target has hardware >> divmod insn or divmod libfunc (in the libfunc case, no hardware div >> insn). Please see divmod_candidate_p() in the patch for cases when >> the transform gets enabled. > > Great. Thanks. Hoping to make some progress on the actual patch in the > next couple days. Thanks! Regards, Prathamesh > > jeff