From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 95A1824A074 for ; Sun, 14 Sep 2025 15:23:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757863414; cv=none; b=qH0WDkDAkPVAj8EBnCRdJ8cJ4fK0cFqaMIRKq6Qp9pUy/Dw/p/qxWcVpIhJs2/Qj8guWd+Yc6NDJLqwlV3uTu7j4eZGDaNB1FybqGK1uIVrpnB9O7mx8o03iBWm2RXSuLUbaccak3MzOfaUKkMUTkpA0usGKIKnlZsfkI2sy0o4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757863414; c=relaxed/simple; bh=8NYf9coXNvo+CKvd3PQC/k00nVwc072Wh3ZJJ2Pl9fk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=i7FiAXS+kBqJBEi1eCAdTsPa6CJB2bJjYijwrHlr0tR9Eb3zqQe7ExFsj2IfhbSulYV5Sv6wieRuZr3d4NsGNRAi8EYdAtVb3vHS4F5VYMxp7DgykVrd2WXImCoIE8ZdtDG3yq4FivB6dbz4XD3SBY2FPNWcJjFH30bWH+qhrRo= 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=A0X3g4Hb; arc=none smtp.client-ip=209.85.221.48 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="A0X3g4Hb" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-3e9ca387425so401024f8f.0 for ; Sun, 14 Sep 2025 08:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1757863411; x=1758468211; 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=JOt3V+aHVyJOvr0bJuCBQkzy8j1/yoSplNYVhJArnhk=; b=A0X3g4HbfPVekgy7B6tFAIBiKjPbcTRtSC/0Rhys0wS68fXzYH4zed7cngGcep3xiT aPcUHk1A5uV6/+JZ6R7MmYF2DTldzUWCgSlAGIPMSs3eMt9e5kLLujUDGfXfyma8RrmB XOAzHFGWb5NF6PekKGvfxFhmbKIM3lYt42DXOR5esoqEWW1mRfymalYGziH5CBKjiP++ OUyqNJCAg0CjR205ASh9A+gatnaSrsQfnPSbyS2+NeFKynzPkUqB+EBq3OrRGzm/YHD0 aP4tNmLLK+hz/TAXr8RjH3EGz+QhwHxBZwYMSS9a/e8eXi2/qUwhqV1kq+mJyHbA80cG YBxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757863411; x=1758468211; 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=JOt3V+aHVyJOvr0bJuCBQkzy8j1/yoSplNYVhJArnhk=; b=udA5w4dq6nGb5bL7KuLJKweohMQ0Ro6rr/4X6wYl8V1r+XZdygbavMsgpIw5ZuJVGC df1XMhsiuWPD70Pdsxocds5Cnh2WU32RIwH2mMM7lVVm7uhixyGz+apPC7wHBEEPNpx9 X3rBxO7QFUoXVHGMgTK/PS+1mTxNFFcdERZ8a49v2/LTEufYuuBBEHe/p36muj/+220h 3NJ0TnKlTkkjOGA/n+ermCeh1hlHULv+qXR9kjLrFkvgAbPL5zCHBeCDZ/WTY0GqJbZA cXue3WcSDpNQKMVXcJAB7GmqXXJG0pHul5YCSHup/FLAMVSW345M1n2dZqbzJXZnC4mk 3R6A== X-Forwarded-Encrypted: i=1; AJvYcCUml/GZLfVBubX3d3qxJfd+kkL1+G6LHIUWFy2Mym8sIV9PNDDEI6mhl5/zasL9VMCID8PiW0nXJEqib+DxSwwP@vger.kernel.org X-Gm-Message-State: AOJu0YzMXfFSNrPfD8ITcijOSTyFj6KzUreWffCIOYRv25WsEmLe9rTq 3yskbXAgiJpdYL7xkbpTQbtKwoRQSN3B9RtpDlfm6915eFeaAAwNvKyckFREDSkVow== X-Gm-Gg: ASbGncuNHPu++OI1cE4aD+HoQgi/K/5UaMxmZyQHyIIs8IeheZqw6Qm5sQ4qqTm2QVM k/7CJTiqv0wRnx8JuBdFeehiKckxV3aBEgxtyjrkGOv7qC44JtewWoIIZ3F7civjmKHV8Py+zBC jNmKMFZnauTfgLKIPNv7oxrF2BV/ck/+5QFGdwE6y4IgJMkmzCXe58NtOPnFQhQdR4V0v4VtMce wCPa1zSiYFYhp5o5YG5KH03j7TGaF6UzUxd/CIM4oF0hzhBqbHZVkBv7pITiHbbPFzTXo6YHWHc BLb2ArlppCZ1c9/v10/HzZOW9rOY9pRbaAxgo0Sktu5kSZOiheN6sTXd2tcukdxXQlL6Dr+ccIt /qBlLL/ChnUSa+spNYehRtYDeoH87u9tMj1R9z5RwyUNdqXQV257n X-Google-Smtp-Source: AGHT+IEt7qPuq7Yxuutfmmcy5MynzxDDs3PjTSViqJCKN6iUZaSU1LtFMyeZXzNuJZteNNhBWf9ekA== X-Received: by 2002:a05:6000:1acb:b0:3e5:d2f1:403d with SMTP id ffacd0b85a97d-3e7659e981fmr9670986f8f.36.1757863410879; Sun, 14 Sep 2025 08:23:30 -0700 (PDT) Received: from [172.20.3.155] ([12.157.112.82]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-260b851f76fsm48494055ad.20.2025.09.14.08.23.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Sep 2025 08:23:30 -0700 (PDT) Message-ID: <26895e7a-5d54-4c89-aeb4-bcd094ba081d@suse.com> Date: Sun, 14 Sep 2025 17:23:29 +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> 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 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. Jan