From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 731BDCCD195 for ; Fri, 17 Oct 2025 09:07:06 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4cnzV10HTZz3069; Fri, 17 Oct 2025 20:07:05 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=35.162.73.231 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1760692025; cv=none; b=ULqw4/dlb6m5gZW41+gnLfEOnLPgIhuZJueXftGKeZsuxZQc0rJNhDTNwp8pgBxwh1LGHqdj9a/iqAdfbC1Q1oRyxVPQx7rtRZt2lK0BhdYbnfLRh6pHzCtQ/zJCwvupJzdWj1DOnx2MdYGLhgWBsdAGqW0WncZrxQjg9qCNGznuUV7/u0Pxh9EnzyUhgVL9AvaxgnOWGffktXTTbQp1+QtUFXhs+5W2RmaUC64MkL1RBLb7fIEP/mHUNJQoc95wWnRSoQwwUqt7403tAOjNZDnuLxDkArAd1V0+GKG9facS72Ve7kDIQD/ElmIrsFkX96Pct0jJCPlb/vz+6oihmw== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1760692025; c=relaxed/relaxed; bh=QGaAvozmIqIzV143yBTS5nQtsGF8X9DZFIMkdv4YYLs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=hh2cQzH9+KD7bbs3TCEN4LzEuAcyMLOqtKTOVd1TdJgbgsY9mNp3+zlZ70nU7buD7DsJ1qCLBdqQrXJTGPbFZbEA4l5/s9qbGfVzqUW/AciBY4ook72VEndSdvIPJCkAmtmlWEp7MrZcXPrNCPQQ40T0No5Kep0dtJFb1i0pjHPLC7fyVoByKEpGCfszhAm+ubcvILY2oESUt626kUkeqfHgweVcySHNipfqAdrKpFCazs6GmNK2ENDEDansKK2D8s9ibj7QdCvEbiFyTFYWPXkWmM3o33imAbj1IU/wHO+XIbrn70AxLDL4xsJLaQmHGUsRHEXg+oy1Q84p8BVnhw== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com; dkim=pass (2048-bit key; unprotected) header.d=amazon.com header.i=@amazon.com header.a=rsa-sha256 header.s=amazoncorp2 header.b=BOOX6eci; dkim-atps=neutral; spf=pass (client-ip=35.162.73.231; helo=pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com; envelope-from=prvs=378230090=farbere@amazon.com; receiver=lists.ozlabs.org) smtp.mailfrom=amazon.com Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=amazon.com header.i=@amazon.com header.a=rsa-sha256 header.s=amazoncorp2 header.b=BOOX6eci; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=amazon.com (client-ip=35.162.73.231; helo=pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com; envelope-from=prvs=378230090=farbere@amazon.com; receiver=lists.ozlabs.org) Received: from pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com (pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com [35.162.73.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4cnzV013dWz2xcB for ; Fri, 17 Oct 2025 20:07:03 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazoncorp2; t=1760692024; x=1792228024; h=from:to:subject:date:message-id:in-reply-to:references: mime-version:content-transfer-encoding; bh=QGaAvozmIqIzV143yBTS5nQtsGF8X9DZFIMkdv4YYLs=; b=BOOX6eciSx3xjIRB284rvqYrgjf7NfljgNrxhyley679sxZWIfCUpzEs mjuIw0+J7T7JWqXMKVz7MMszxyoGUH14CkqAyQZL2vJLlVOycbazsXexR DMQbhvI6qiT//jpCgzLSnqRXdEQszt4sLl9NW+o8AusjIjTfs12SPdEwO Owk5QuptnBCv4Fnke2NUEQEU112BNw9mOcg6Co+CLnYxJmYtKyUB/iYEr KT7IvLW5vS9psx5twrVjraovfozWaOB0z9R0m6L0PE1o/qoNiBLs5PmOA QVqKoAEChqFuW9DmyJS0g+JvAtXQRXGylw1z2vI4y6ZirOtUKXCmJcuS7 A==; X-CSE-ConnectionGUID: zWrYvXLbQjiOYymOyGvz5A== X-CSE-MsgGUID: 76/3AHtyRme5brVPZGOntA== X-IronPort-AV: E=Sophos;i="6.19,236,1754956800"; d="scan'208";a="4877962" Received: from ip-10-5-6-203.us-west-2.compute.internal (HELO smtpout.naws.us-west-2.prod.farcaster.email.amazon.dev) ([10.5.6.203]) by internal-pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2025 09:07:02 +0000 Received: from EX19MTAUWB002.ant.amazon.com [205.251.233.111:7581] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.44.167:2525] with esmtp (Farcaster) id c402a081-eaf9-4041-86d8-805021e16bf5; Fri, 17 Oct 2025 09:07:01 +0000 (UTC) X-Farcaster-Flow-ID: c402a081-eaf9-4041-86d8-805021e16bf5 Received: from EX19D001UWA001.ant.amazon.com (10.13.138.214) by EX19MTAUWB002.ant.amazon.com (10.250.64.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.20; Fri, 17 Oct 2025 09:07:01 +0000 Received: from dev-dsk-farbere-1a-46ecabed.eu-west-1.amazon.com (172.19.116.181) by EX19D001UWA001.ant.amazon.com (10.13.138.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.20; Fri, 17 Oct 2025 09:06:46 +0000 From: Eliav Farber To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH v2 04/27 5.10.y] minmax: clamp more efficiently by avoiding extra comparison Date: Fri, 17 Oct 2025 09:04:56 +0000 Message-ID: <20251017090519.46992-5-farbere@amazon.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20251017090519.46992-1-farbere@amazon.com> References: <20251017090519.46992-1-farbere@amazon.com> X-Mailing-List: linux-erofs@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [172.19.116.181] X-ClientProxiedBy: EX19D044UWB002.ant.amazon.com (10.13.139.188) To EX19D001UWA001.ant.amazon.com (10.13.138.214) From: "Jason A. Donenfeld" [ Upstream commit 2122e2a4efc2cd139474079e11939b6e07adfacd ] Currently the clamp algorithm does: if (val > hi) val = hi; if (val < lo) val = lo; But since hi > lo by definition, this can be made more efficient with: if (val > hi) val = hi; else if (val < lo) val = lo; So fix up the clamp and clamp_t functions to do this, adding the same argument checking as for min and min_t. For simple cases, code generation on x86_64 and aarch64 stay about the same: before: cmp edi, edx mov eax, esi cmova edi, edx cmp edi, esi cmovnb eax, edi ret after: cmp edi, esi mov eax, edx cmovnb esi, edi cmp edi, edx cmovb eax, esi ret before: cmp w0, w2 csel w8, w0, w2, lo cmp w8, w1 csel w0, w8, w1, hi ret after: cmp w0, w1 csel w8, w0, w1, hi cmp w0, w2 csel w0, w8, w2, lo ret On MIPS64, however, code generation improves, by removing arithmetic in the second branch: before: sltu $3,$6,$4 bne $3,$0,.L2 move $2,$6 move $2,$4 .L2: sltu $3,$2,$5 bnel $3,$0,.L7 move $2,$5 .L7: jr $31 nop after: sltu $3,$4,$6 beq $3,$0,.L13 move $2,$6 sltu $3,$4,$5 bne $3,$0,.L12 move $2,$4 .L13: jr $31 nop .L12: jr $31 move $2,$5 For more complex cases with surrounding code, the effects are a bit more complicated. For example, consider this simplified version of timestamp_truncate() from fs/inode.c on x86_64: struct timespec64 timestamp_truncate(struct timespec64 t, struct inode *inode) { struct super_block *sb = inode->i_sb; unsigned int gran = sb->s_time_gran; t.tv_sec = clamp(t.tv_sec, sb->s_time_min, sb->s_time_max); if (t.tv_sec == sb->s_time_max || t.tv_sec == sb->s_time_min) t.tv_nsec = 0; return t; } before: mov r8, rdx mov rdx, rsi mov rcx, QWORD PTR [r8] mov rax, QWORD PTR [rcx+8] mov rcx, QWORD PTR [rcx+16] cmp rax, rdi mov r8, rcx cmovge rdi, rax cmp rdi, rcx cmovle r8, rdi cmp rax, r8 je .L4 cmp rdi, rcx jge .L4 mov rax, r8 ret .L4: xor edx, edx mov rax, r8 ret after: mov rax, QWORD PTR [rdx] mov rdx, QWORD PTR [rax+8] mov rax, QWORD PTR [rax+16] cmp rax, rdi jg .L6 mov r8, rax xor edx, edx .L2: mov rax, r8 ret .L6: cmp rdx, rdi mov r8, rdi cmovge r8, rdx cmp rax, r8 je .L4 xor eax, eax cmp rdx, rdi cmovl rax, rsi mov rdx, rax mov rax, r8 ret .L4: xor edx, edx jmp .L2 In this case, we actually gain a branch, unfortunately, because the compiler's replacement axioms no longer as cleanly apply. So all and all, this change is a bit of a mixed bag. Link: https://lkml.kernel.org/r/20220926133435.1333846-2-Jason@zx2c4.com Signed-off-by: Jason A. Donenfeld Cc: Andy Shevchenko Cc: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Eliav Farber --- include/linux/minmax.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/minmax.h b/include/linux/minmax.h index 8b092c66c5aa..abdeae409dad 100644 --- a/include/linux/minmax.h +++ b/include/linux/minmax.h @@ -38,7 +38,7 @@ __cmp_once(x, y, __UNIQUE_ID(__x), __UNIQUE_ID(__y), op)) #define __clamp(val, lo, hi) \ - __cmp(__cmp(val, lo, >), hi, <) + ((val) >= (hi) ? (hi) : ((val) <= (lo) ? (lo) : (val))) #define __clamp_once(val, lo, hi, unique_val, unique_lo, unique_hi) ({ \ typeof(val) unique_val = (val); \ -- 2.47.3