From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE649145B27 for ; Sun, 14 Sep 2025 18:10:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757873455; cv=none; b=RALhugPUDRpJUXKqWWh19ZzM7RJESyDKJsVontN5sIXDn7n4bUs5PPN1nB3Ekl1n/vU3tZmMi9tHaHZGsJhETZNZHXP3USCWSrLgQR1+Gy91nJy87BgMc8bBehmmheTeNHmkkxzw6hETUIMVeu3JzNgKVFogjZxVNc3RCaeDz2w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757873455; c=relaxed/simple; bh=qeE8iPKRG5uDrWg1F1nmQi3gUwXMud4txTgO8NCAVqE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=A2e+uLL9EnR4SO7hM6tSe0RoUicFG0M/kb+O+miPrxUniSbgejQQSTIxgTCeiEjfVPMIJOyOK678cQIcN1v4wl7xk11fM74g344uOlqmfmxykd68cSGAnYEl0S7xwj2dhjBSObNVGXWqSqRYheTY5O/OlXV68qhDaLJ3tUfgeY0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Br81H1vK; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Br81H1vK" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-45b9c35bc0aso30864495e9.2 for ; Sun, 14 Sep 2025 11:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1757873451; x=1758478251; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1Wvn0TEVkKpRBACOdDDewW6sThAHqXbkPFybLQwcOf0=; b=Br81H1vK7uUBKaPRZlSlObyXON5iSRUagUeiXsSG6Be/HSaUBcZT0Sy3BvTWzAzwGz m6qkVF3hWIbTvKG8WoI0Ur/br7LKo2B+6QRFWhpXarIO3iQQlJnnNYlGqTNK2DwGFzh/ jQjh87r5u0PqIY8TpjuHtHV/d1yMYBOSrLyQL7UaDErUG6NnmBCJ/L393FzvjWT7TmKH m8Rh5TFtDbfU97zuK1AWs16CevyL5ga86FMIybJ5n0wxqHZvHqtbRbyN4RBkhVdz6Skz iIU2LNujkHLS50VwcO4G9oJb/YqVG+MSdc3YZpNOEPwFyYqvqJL7bUs4WP1oH4wHu/dl ++sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757873451; x=1758478251; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1Wvn0TEVkKpRBACOdDDewW6sThAHqXbkPFybLQwcOf0=; b=iGBoRMowKuAb6Gbf4qQgg2Ahmf0kIJJhFz/Z/AXnEAEuu8GhrBZknf0o744iASFSbA N80gy1Y2ntz0uLaF5629GPLIOJkWlnlmAE6QTxJ5oEVponO2YPnYjO3V28sXy1uyDSNP ccGUtPIFXRvaEj1o9EWBzG5BFqnM9cJtOj0zWdYFVG7krYwYXY3dSHC9x37Pbg9R11r2 IVIqUICYb7IwnCY61Sl17koFRHBnBhsOyj1rqlju/5bu+oKY4iQMZXAUdmBENf8EsM7o o+2DuKxV2ZJP+8CPwBdMOoOlM5PBD/5JmuIJ7Jg/G5pmAHN7X1niqPNLhUzu5d6u1Ibm NYZA== X-Forwarded-Encrypted: i=1; AJvYcCVpH1NEA5RRN5TiufQo7UAq4jFL02Cvy+1k7o915fVM8iAcsaKj24Yz2PXozqpisoKtsM0O1rvphjIsPSuCilhc@vger.kernel.org X-Gm-Message-State: AOJu0Yy0IMoaCl+ahdEcHUL8lYs8TVhsYCLzVqGai3EBJ6bNgOdqb+e+ TaG8Y8Q6jBKwVbSbxduAPbfqDL/fBEeFRkBvAZ866tlzFTk5FPrWzHHTfL5CUH+voA== X-Gm-Gg: ASbGncswV1reowopEodMW73bBAAQiVjixiHhwzOgbY5os5DyDxZ74u5UZFalpB8WQ/8 E7EkcxpZLCkoDVy2/hfAhARwCIH7KRgNEAP2F6W9fZBbW3S/YD/T6USyE67I2LIpi0+wK7DbV4+ OCDBbNKLtmXRDY2zUXafo0Gyg1R9M0WIBfzEJ4qYiF7LrcbWk/qartcI6/HIUGykbkC0k8fohjf rKCdWAMwyloa7r7sNLdrblPUkyAiZjlxDPm/tk2xeb1SV8NCkraDGyHyd9/n8bKqK0s3t4b/jwd 4PQQaH6EJoA3hmTyDHUgUchIrbjffhIwyl5m8umkcZ3rJjJ1lgzsYJ4D+7djgfX1ldTx1uag0TE YN9tpF29c5BfwY3+Xtv+GQ8pHTkGuS8w= X-Google-Smtp-Source: AGHT+IEaIODzbmaCqSuYC8bvdc2mHEamj0hENbLyjt71f4vRlCc63+P4+bQNykM+v/qDtuBBbg5HcQ== X-Received: by 2002:a05:6000:2c0c:b0:3c6:97ae:a574 with SMTP id ffacd0b85a97d-3e7659ca750mr7833512f8f.24.1757873451209; Sun, 14 Sep 2025 11:10:51 -0700 (PDT) Received: from [172.20.3.155] ([12.157.112.82]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-32dfc974426sm5928838a91.20.2025.09.14.11.10.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Sep 2025 11:10:50 -0700 (PDT) Message-ID: <1308e9fa-90c8-4c52-b53d-afd24542b4c8@suse.com> Date: Sun, 14 Sep 2025 20:10:49 +0200 Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Unaligned access trade-offs for SFrame FRE layout To: Rainer Orth Cc: Indu Bhagat , "linux-toolchains@vger.kernel.org" , Jens Remus , Sterling Augustine , Pavel Labath , Andrii Nakryiko , Josh Poimboeuf , Steven Rostedt , Serhei Makarov , Binutils References: <9d104c46-855c-4b36-8226-1f59b59e455c@suse.com> <26895e7a-5d54-4c89-aeb4-bcd094ba081d@suse.com> Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14.09.2025 18:18, Rainer Orth wrote: > Jan Beulich writes: > >> On 14.09.2025 16:39, Rainer Orth wrote: >>>> On 12.09.2025 19:34, Indu Bhagat via Binutils wrote: >>>>> TL;DR: Thinking and experimenting a bit on the possible approaches for >>>>> avoiding unaligned accesses in the SFrame FRE layout (in SFrame V3), I >>>>> am not convinced that avoiding unaligned accesses for performance is >>>>> worth it. IMO, forsaking compactness for avoiding unaligned accesses is >>>>> not a good trade off for SFrame. >>>>> >>>>> Problem Statement >>>>> On architectures such as x86_64, AArch64, and s390x, unaligned memory >>>>> accesses are handled transparently by the hardware but incur a >>>>> performance penalty. >>>> >>>> As you say in a reply, may incur. However, shouldn't we also consider >>>> possible ports of SFrame to architectures which don't handle this as >>>> transparently? Off the top of my head I don't, for example, recall >>>> whether RISC-V requires unaligned accesses to be handled transparently >>>> by the hardware. >>> >>> look for STRICT_ALIGNMENT in the GCC sources in gcc/config. While >>> several are embedded targets, there's also sparc in that list. >> >> But is this setting a good reference for the purpose here. For RISC-V it's >> command line (?) controlled (TARGET_STRICT_ALIGN), despite the spec saying >> >> "An EEI may not guarantee misaligned loads and stores are handled invisibly. >> In this case, loads and stores that are not naturally aligned may either >> complete execution successfully or raise an exception. The exception raised >> can be either an address-misaligned exception or an access-fault exception." >> >> It's okay for gcc to make assumptions (assuming they're properly documented), >> but I don't think such assumptions can be extended to a discussion like the >> one here. > > please look at the actual code: > > gcc/config/riscv/riscv.cc: TARGET_STRICT_ALIGN ? 0 : 1); > > on RISC-V, the setting is controlled by -mstrict-align. On most others, > it's just 1. Precisely my point: By (not or wrongly) using the command line option, you can break things. Whereas such breakage wants avoiding here. > I'm just pointing out an easy way to answer the question: there's a > considerable number of strict-alignment targets. If they is relevant to > the discussion at hand is for the SFrame developers to decide: if they > come to the conclusion that none of the affected CPUs is of interest, > that's certainly fine. However, from my recently experience porting > LLVMs openmp to SPARC, fixing this as an afterthought takes some time > and analysis, so you need to decide if you want to support such targets > or not. Yes, that's exactly why I brought up the point. Jan