From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) by sourceware.org (Postfix) with ESMTPS id 388FC3858D1E for ; Tue, 25 Apr 2023 08:40:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 388FC3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-546dad86345so4267852eaf.0 for ; Tue, 25 Apr 2023 01:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1682412034; x=1685004034; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j69UOFH4Q5kIS1waf1MljtGnwFjvvdGTDJD1WhaySOM=; b=3d0BLWbkTugVw1ARt/h2HhXVY4KO+XRDm4wTBIowd74h2pqa/s35/UaN9IY86ARxRH do5etFuomAFObMzDikrjsbhqGXcmPB4+mTIixeN1fNzR0qGaEEvVON7FvKLv/ZVCAruU /WA+14bRS32CWs0ZhB2mYkgVLnPnUBxC/wrskpqVBZmvExhcjFI75ImyJiSExsDImVfB trZgqOc9pfLQBlLvIl8ZamXEPnvg/nTPr3Ub1LYNjF6aYe1E6lMSB+4lAxG3ytKmBP7c gGn1sHP64VGuCOWA0tAVopmIaIKUVWrQi7hZ28qGgHffDUEaWYIhal8EMEn4JgYfIeML Bsug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682412034; x=1685004034; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j69UOFH4Q5kIS1waf1MljtGnwFjvvdGTDJD1WhaySOM=; b=VkrNOoAO7kRb8eRUxxygGuq8vjMS2bl+a3xRhuzvpRuTuzRJmXn5xL0dymKDMVSFr6 OMMsfxIDyh9K2X+kd7O6QOJAhAMGVhmdgCw2CF5T4fKqnqksHyReqDzas2dyQxyCNQJD KRDZ2aP6ncmuCjgEW7edPoO+cTmbmpKOv4tHYoUMVvnS0sGHonXhMestUR7cnqn4bLsR A08ALEdqr65oC03Aj3CozktJDbfIiIs0arv9Aesc9Zi3IA3fSRSyf2M2k+7uzonWcM+t HLzF8+X/zjh1d2ky2aLNlNFLjBCTSwW6e6dbZ3Qci8wf4kBo5mR8IT+OEhq05AIG5bM8 YNPw== X-Gm-Message-State: AAQBX9e1mhzbZG8Bb6q7WUzwkUSwuNjEe3lgyOVoVjzPRaVmjy13yzes 1A6hpAwPL0zkAArCRQhaK/QbLFXUhZLkKWpzjGU4DQ== X-Google-Smtp-Source: AKy350ZoHCNtNNNL05x1QLHMXuacqqXpaJOue4W47h/msVb8SZTGM5aVQ8/b+FEAj3Smm2E59PKHgfUvEC9AO0bK4dI= X-Received: by 2002:aca:a856:0:b0:38e:6ba9:6491 with SMTP id r83-20020acaa856000000b0038e6ba96491mr7670898oie.50.1682412034519; Tue, 25 Apr 2023 01:40:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nelson Chu Date: Tue, 25 Apr 2023 16:40:23 +0800 Message-ID: Subject: Re: [PATCH v2 0/7] RISC-V/gas: insn operand parsing To: Jan Beulich Cc: Binutils , Palmer Dabbelt , Andrew Waterman , Jim Wilson Content-Type: multipart/alternative; boundary="000000000000af159c05fa25137b" X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000af159c05fa25137b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan, On Fri, Mar 10, 2023 at 5:24=E2=80=AFPM Jan Beulich wro= te: > (v1 series was "re-work register named symbols avoidance logic") > > This addresses some of the anomalies I've observed. There continue to > be questions towards consistent overall behavior - see remarks in the > individual patches. > > An assembler with the full series in place was used in a gcc 12.2.0 > testsuite run (cross build on x86, so no execution tests), resulting > in no new test failures (there were a number of pre-existing ones, > though). > > 1: minor effort reduction in relocation specifier parsing > 2: drop "percent_op" parameter from my_getOpcodeExpression() > 3: avoid redundant and misleading/wrong error messages > 4: don't recognize bogus relocations > 5: relax post-relocation-operator separator expectation > Except this one I'm not sure if we should accept or not, others look good to me. The gcc/binutils regressions of riscv-gnu-toolchain looks good with this whole series, including the fifth patch, so I guess that is because the current codegen and inline assembly developers are all expect () after the %hi/%pcrel_hi/... modifiers. I don't know if we should relax the usage of modifiers here, but at least the regressions prove that there should be no effect for now, even if we commit the patch. The only thing is that we may have different behaviors as llvm, but since llvm only accepts the () after the modifiers, we have already behaved a little differently. Thanks Nelson > 6: test for expected / no unexpected symbols > 7: adjust logic to avoid register name symbols > > Jan > --000000000000af159c05fa25137b--