From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85561 invoked by alias); 3 May 2017 06:10:18 -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 85539 invoked by uid 89); 3 May 2017 06:10:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=recommend, wondering X-HELO: mail-ua0-f175.google.com Received: from mail-ua0-f175.google.com (HELO mail-ua0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 May 2017 06:10:16 +0000 Received: by mail-ua0-f175.google.com with SMTP id j59so96307916uad.0 for ; Tue, 02 May 2017 23:10:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3W3ON3f7LTGwWZBaD8eFLhlBqaJp4vMQkPnkj+1wGxY=; b=bSk/fjC/5LIej2TH5h7NerxNDq0POpjk0psUlIofGkmUAvEK/h7KIDT5wWSOrR/TE0 1CGw4pftcmrxkDS4/+VpjGf0dJ5AcibG/Ao4+A2IZavIcdpCp+1Ib/yRdMrsuDYfGmEW eDaV2k2b8diAcrgkRoHrNQ+rdl6X/JlwNPsb90/cw1oZQCxdVLwbaUrD7W/Qt/clR4ld lEid/c9r2bUjT9S3J2yEaA9CYqebCQdV7zMrSzwAlrHFpm3d0hvJzbLoSqWu+3gEy9JT r3OuljYATRB9Gl33kPT25/BUUZ27wGOCFMvkiUS0Fh2HNFRJO3dSpvdVI9NCpLITm2iK rdZA== X-Gm-Message-State: AN3rC/7hNM/n9MAjukczj4l5VRNwLH42zTAEeLS+0Py92NUmXioBA0rz dhsP/u4gqHN8XdCoc/AjRtL5CniZDw== X-Received: by 10.176.64.1 with SMTP id h1mr11985600uad.18.1493791816720; Tue, 02 May 2017 23:10:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.49.206 with HTTP; Tue, 2 May 2017 23:10:16 -0700 (PDT) In-Reply-To: <272376f2-178f-4d42-bc88-1555b54282f0@pobox.com> References: <49e81c0b-07a4-22df-d7c3-2439177ac7cf@pobox.com> <20170427080932.11703-9-daniel.santos@pobox.com> <272376f2-178f-4d42-bc88-1555b54282f0@pobox.com> From: Uros Bizjak Date: Wed, 03 May 2017 06:17:00 -0000 Message-ID: Subject: Re: [PATCH 09/12] [i386] Add patterns and predicates foutline-msabi-xlouges To: Daniel Santos Cc: gcc-patches , Jan Hubicka Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-05/txt/msg00163.txt.bz2 On Wed, May 3, 2017 at 12:16 AM, Daniel Santos wrote: >> I'd recommend that in the predicate, you check match_parallel from the >> bottom up, since subexpressions on the top are already matched, and >> you can have different number of subexpressions at the top. >> >> Uros. > > > OK, this all makes sense then. I was using const_int tags to differentiate > the insns, but omitting the insns for the leave (for example) are what > ambiguates them in the first place. > > So one question I never had resolved is rather or not the order the insns in > a parallel matters. From your suggestions, I'm guessing that it would be > perfectly OK for the leave insns to follow use symbol and then have the > register restores after that, even though that wouldn't make sense from an > assembly level because we would be writing beyond the stack pointer. Am I > reading this correctly? If so, then putting the register save/restore > matching in the predicate (checking top down) and having all others in the > pattern make great sense and should both simplify it and make it more clear. The order of subexpressions of parallel in general does not matter. > Also, I'm wondering if there's anything wrong with calling ix86_gen_leave () > and plucking the insns out of the generated parallel insn and moving that > into my own parallel rather than generating them in my own function. I > guess all the matters is what is cleanest. Hm... I'd rather see subexpressions generated "by hand". Uros.