From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100591 invoked by alias); 17 Feb 2019 17:22:04 -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 100559 invoked by uid 89); 17 Feb 2019 17:22:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:ip*209.85.166.195 X-HELO: mail-it1-f195.google.com Received: from mail-it1-f195.google.com (HELO mail-it1-f195.google.com) (209.85.166.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 17 Feb 2019 17:22:01 +0000 Received: by mail-it1-f195.google.com with SMTP id z124so7405342itc.2 for ; Sun, 17 Feb 2019 09:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J/WPQsyVz84q39zrj9lvVMqB/xdA834XQKO3Z7KV+us=; b=dUm9ZUgAF7B3jTHHhhmN0/G98qs/ljDNwPbWQm3RgGOCXufog5rAsFtk1TsSMQxA45 bpEN5GeDDbuQztm5UvhhKMGXVjGBzDRR95JnBayzjWwYP8jtororkC5iRMiWrCEhst8Z ID0WLBMM4haRTYyqiW4cuzoafo6uJY/zDN2Lpo+oTCMzVZkUg9kZ81eqaqNZGs6qT0Jr RfcgVaMuFCedeifGG3SmBt53jAoqhXneHoZGUe/dyiMlOmWfeaOM+VmOMIhJgQMHAq4x PuYCQsiCMBw+STmd7XL6kNZ1rRbZbwLCDOwXZEumTAtz5fiDbZa5aH3Nd0wPs12fvZrp oXpA== MIME-Version: 1.0 References: <20190216224032.4889-1-hjl.tools@gmail.com> <20190216224032.4889-39-hjl.tools@gmail.com> In-Reply-To: From: Uros Bizjak Date: Sun, 17 Feb 2019 17:22:00 -0000 Message-ID: Subject: Re: [PATCH 38/41] i386: Allow MMX vector expanders with TARGET_MMX_WITH_SSE To: "H.J. Lu" Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-02/txt/msg01408.txt.bz2 On Sun, Feb 17, 2019 at 6:15 PM H.J. Lu wrote: > > > > On Sat, Feb 16, 2019 at 11:46 PM H.J. Lu wrote: > > > > > > > > > > PR target/89021 > > > > > * config/i386/i386.c (ix86_expand_vector_init_duplicate): Set > > > > > mmx_ok to true if TARGET_MMX_WITH_SSE is true. > > > > > (ix86_expand_vector_init_one_nonzero): Likewise. > > > > > (ix86_expand_vector_init_one_var): Likewise. > > > > > (ix86_expand_vector_init_general): Likewise. > > > > > (ix86_expand_vector_init): Likewise. > > > > > (ix86_expand_vector_set): Likewise. > > > > > (ix86_expand_vector_extract): Likewise. > > > > > > > > Please move this initialization to .md files. We don't support V2SF, so > > > > > > > > (define_expand "vec_setv2sf" > > > > [(match_operand:V2SF 0 "register_operand") > > > > (match_operand:SF 1 "register_operand") > > > > (match_operand 2 "const_int_operand")] > > > > "TARGET_MMX" > > > > { > > > > ix86_expand_vector_set (false, operands[0], operands[1], > > > > INTVAL (operands[2])); > > > > DONE; > > > > }) > > > > > > > > should remain false, while in: > > > > > > > > (define_expand "vec_setv2si" > > > > [(match_operand:V2SI 0 "register_operand") > > > > (match_operand:SI 1 "register_operand") > > > > (match_operand 2 "const_int_operand")] > > > > "TARGET_MMX" > > > > { > > > > ix86_expand_vector_set (false, operands[0], operands[1], > > > > INTVAL (operands[2])); > > > > DONE; > > > > }) > > > > > > > > we should use TARGET_MMX_WITH_SSE instead of false in the call to > > > > ix86_expand_vector_set. The same change for the other MMX modes: V4HI > > > > and V8QI. > > > > > > > > Same for other exported vector initializers: ix86_expand_vector_init > > > > and ix86_expand_vector_extract. We support V2SI, V4HI and V8QI, but > > > > not V2SF (non-MMX modes are agnostic to mmx_ok argument). > > > > > > > > > > There is limited support for V2SF with MMX. My goal is to emulate > > > all MMX features with SSE so that -msse2 -mno-mmx works for all > > > MMX codes which don't use MMX inline asm. Leaving out V2SF > > > emulation creates a hole in my implementation. Do you have testcases > > > to show issues with V2SF emulation? > > > > No, but V2SF should be avoided from emulation. > > Then -msse2 -mno-mmx won't work on some MMX codes like: > > #include > > float > foo (__m64 x) > { > return ((__v2sf) x)[0]; > } > > Is there any reason why it shouldn't work for -msse2 -mno-mmx? Does this require 3DNOW insn? If not, it is OK also for V2SF. Uros.