From patchwork Wed Mar 1 10:41:17 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Uros Bizjak X-Patchwork-Id: 734163 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vYBnt2Z0bz9s7q for ; Wed, 1 Mar 2017 21:41:36 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="gJa00Sd/"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; q=dns; s=default; b=j7soX/8/yyuBJyO r/qf6aUOJ6udXYlOAaX5rOZ+ozXCPUojYrUE5FJHc6J66dxjJ13n3eX50kCxcia2 R1zqBdGyvraisYRGCFx71uXOT6Nozud8VX3Jnk4Yfm/H2eFRi9NdDQ6+K0dbQ0Qo vmN46oo4u9q8revV6rsKZTJ9/fHs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; s=default; bh=fWqbioWYANjtg9c24KCOI gazkcg=; b=gJa00Sd/nYG8YEjnh4m210L2akFM1EZdHqaqzMdr5lK0k7gmvzB10 wO2+tLG5sInKus02C+96Aij0qVIqLgQPo5iqMVlj7eO88RVWcErLjWvktoRGYPA6 Ror2kxCULDS3czXTCkS0INmZd+2SmrcldLvNdPkSVEGAQID7rWkBUo= Received: (qmail 68592 invoked by alias); 1 Mar 2017 10:41:21 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 68581 invoked by uid 89); 1 Mar 2017 10:41:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-23.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=double-register, doubleregister, H*f:eBfUC46PWuqe, rdtscp X-HELO: mail-ua0-f195.google.com Received: from mail-ua0-f195.google.com (HELO mail-ua0-f195.google.com) (209.85.217.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Mar 2017 10:41:19 +0000 Received: by mail-ua0-f195.google.com with SMTP id j56so4617093uaa.3 for ; Wed, 01 Mar 2017 02:41:19 -0800 (PST) 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=6Eb6Y/U3yHwX8EQZEIa2iEm7US7GNsvmnk0yyB99SqE=; b=RyiS374c8ilDPmtnpSw5uG03xHMkLiUetxucGpcFTbObh6BoUrBq1lIa1eWBEa3kIP QL3gTDAJY3E41VXD/CgfOZJPlJLyDY+1LS/5SwLD2dIxXgwHdhSti2CpAoR3lFl4DU0Y +xXChoPhKkry6MkYo8uMuZt2FLy7foQ984I3MAwgmD6Pymn/VJ53USboAlXiVgnHWtXw qcvii/DX/ExL+831qMmsqXxx23jMfW4ntih/puZXGnjMeWp+Ao/n+yaqkFFanDjsRpwX ZIDPD4WjC4xoQNGUWa9ENfSrLfV21HlwfSDqi/ljDkmjE3V4nH994er1T/+CW11tcyVM 3WwQ== X-Gm-Message-State: AMke39mADjdz++d5G1TUTSl+vjcrg/unuWsxP8PHceig8se5LWR4nVyXI39aQt3dbrgDKDs6KcoIHq2llxoioQ== X-Received: by 10.176.90.195 with SMTP id x3mr3290926uae.165.1488364877708; Wed, 01 Mar 2017 02:41:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.87.67 with HTTP; Wed, 1 Mar 2017 02:41:17 -0800 (PST) In-Reply-To: References: <20170228110647.GI1849@tucnak> <20170301084822.GZ1849@tucnak> From: Uros Bizjak Date: Wed, 1 Mar 2017 11:41:17 +0100 Message-ID: Subject: Re: [RFA PATCH, i386]: Warn for 64-bit values in general-reg asm operands and error out for 8-bit values in invalid GR asm operand To: Jakub Jelinek Cc: Richard Biener , "gcc-patches@gcc.gnu.org" On Wed, Mar 1, 2017 at 10:00 AM, Uros Bizjak wrote: > On Wed, Mar 1, 2017 at 9:48 AM, Jakub Jelinek wrote: >> On Wed, Mar 01, 2017 at 09:34:53AM +0100, Uros Bizjak wrote: >>> Some more thoughts on 64-bit reg on 32-bit targets warning. >>> >>> Actually, we never *print* register name for instruction that use "A" >>> constraint, since %eax/%edx is always implicit The warning does not >>> deal with constraints, so unless we want to output DImode register >>> name, there is no warning. >> >> Ah, indeed, we don't have a modifier that would print the high register >> of a register pair (i.e. essentially print REGNO (x) + 1 instead of REGNO >> (x)), guess that might be useful not just for 64-bit GPR operands in 32-bit >> code, but also 128-bit GPR operands in 64-bit code. > > The issue here is that (modulo ax/dx with "A" constraint) we don't > guarantee double-register sequence order, so any change in register > allocation order would break any assumptions. For implicit ax/dx, user > should explicitly use register name (e.g. DImode operand in "rdtscp; > mov %0, mem" asm should be corrected to use %%eax instead of %0). > > And, yes - we should add similar warning for 128-bit GPRs. The only > way to use register pair with width > machine_mode is with implicit > operands or with explicit regnames. Something like the following patch I'm testing: --cut here-- --cut here-- Uros. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 2b11aa1..943b2a0 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -17646,13 +17646,16 @@ print_reg (rtx x, int code, FILE *file) switch (msize) { + case 16: + case 12: case 8: + if (GENERAL_REGNO_P (regno) && msize > GET_MODE_SIZE (word_mode)) + warning (0, "unsupported size for integer register"); + /* FALLTHRU */ case 4: if (LEGACY_INT_REGNO_P (regno)) putc (msize == 8 && TARGET_64BIT ? 'r' : 'e', file); /* FALLTHRU */ - case 16: - case 12: case 2: normal: reg = hi_reg_name[regno];