From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id BC58C3854804 for ; Tue, 16 Mar 2021 16:51:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BC58C3854804 Received: by mail-oi1-x235.google.com with SMTP id w65so38779738oie.7 for ; Tue, 16 Mar 2021 09:51:34 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aEyTvz0XxWssKuoMbSVreS6h/AUXf48VVFiPNZ5xUCQ=; b=V/BXMm4pI5zHydh3MaLEn2NMsHJdSv4V2irL2XRrZ0ViDfYaJO1hgA/m9OVKgPijeQ xFCZqnf0HjmB7vsBtttNevtO6H8WmAZpZdbh/qJQs7Op45vAVS203joT0R13n1s9++J5 uZBCHvqaco40zv8Chu9lUdGPE5SPZSvJ0JnodSZ4MaBuhJ7Kiz19r9H3Ebmt0gNHQCBj UA0B1UHAKfN1ZiM3lmviQOBfZxLnCS3rKfQ4W1XosXKVqOJIkXxSP2trSt5NOaY57sDw YkcDEwKtykHD1zmqwGLcGsPPxZ802u7NxwepIwBGfJ108x0uT1UzwSDWYC47F79bEIN2 yfNA== X-Gm-Message-State: AOAM531ksM8CYKurOeZQeQRjfvmnQoJ6HV4eJcPqA1JdMNYxSujHoGqI nqs6lTV0QOuYqw1+u709ShXtgC06oM8CqvZwZMH6c0D9lBA= X-Google-Smtp-Source: ABdhPJxqFCSCDngU6YJ3DSZBg1C114Ngm+IJiiJ2jOmoifiTb25hViCZ2tk4RNUFbMH4aT/r1w6W83yd8lIvHCp0nYU= X-Received: by 2002:a54:468f:: with SMTP id k15mr20917oic.58.1615913494127; Tue, 16 Mar 2021 09:51:34 -0700 (PDT) MIME-Version: 1.0 References: <20210202191209.4036619-1-hjl.tools@gmail.com> <60a3a304-7f33-3727-a39a-5420d26d13a0@redhat.com> <87ft0vzcy5.fsf@igel.home> <87zgz3xf1f.fsf@igel.home> <87zgz3m647.fsf@oldenburg.str.redhat.com> In-Reply-To: From: "H.J. Lu" Date: Tue, 16 Mar 2021 09:50:58 -0700 Message-ID: Subject: [PATCH v6] x86_64: Correct THREAD_SETMEM/THREAD_SETMEM_NC for movq [BZ #27591] To: "Carlos O'Donell" Cc: Florian Weimer , Andreas Schwab , "Carlos O'Donell via Libc-alpha" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3030.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 16:51:36 -0000 On Tue, Mar 16, 2021 at 9:34 AM Carlos O'Donell wrote: > > On 3/16/21 12:10 PM, Florian Weimer via Libc-alpha wrote: > > * Andreas Schwab: > > > >> I don't think this will work in general. Wouldn't it be possible that > >> an operands optimizes to a 64-bit constant in later passes? What you > >> really need is a constraint that only matches a 32-bit immediate or a > >> register. Like "rWf"? config/i386/constraints.md in GCC has (define_constraint "e" "32-bit signed integer constant, or a symbolic reference known to fit that range (for immediate operands in sign-extending x86-64 instructions)." (match_operand 0 "x86_64_immediate_operand")) "er" is the correct constraint for movq. > > Maybe we should to the __seg_fs namespace instead? Wouldn't that avoid > > these issues? > > It might. > > HJ, Does it work to rewrite this using __seg_fs? I tried it. GCC generates worse code. > Otherwise I'll review v5, which I think is better than it was before and > makes forward progress. Here is the v6 patch to use the "er" constraint. OK for master? Thanks. -- H.J.