From: Nathan Chancellor <nathan@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Heiko Carstens <hca@linux.ibm.com>,
Miguel Ojeda <ojeda@kernel.org>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Juergen Christ <jchrist@linux.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
Sven Schnelle <svens@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>
Subject: Re: [PATCH 1/3] Compiler Attributes: Add __assume macro
Date: Thu, 11 Sep 2025 13:42:46 -0700 [thread overview]
Message-ID: <20250911204246.GA69679@ax162> (raw)
In-Reply-To: <CANiq72kJ9L_Kpv9+z5=xZvbWxLRYXpKS-76XwwvQP+wMWsMJtg@mail.gmail.com>
On Thu, Sep 11, 2025 at 09:04:36PM +0200, Miguel Ojeda wrote:
> On Thu, Sep 11, 2025 at 8:44 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > I do not think anyone really owns compiler_types.h so unless Miguel has
> > any objections from the compiler attributes perspective, I think you can
> > just take this via the s390 tree with the other two changes.
>
> No objections from me, and thanks for spotting the OpenMP thing above.
>
> I would say, though, that this is a fairly general and subtle tool to
> have around, so it would be nice to have others chime in. In other
> words, do we want to start using `assume`s? Should we constrain its
> use a bit, e.g. say its use should really be justified etc.? (In the
> Rust side, a tool like this would require a SAFETY comment on top with
> a justification, which may give a developer pause).
I do think justification at the source level (i.e., a comment) would be
a good baseline. I thought I remember a similar discussion around
likely() / unlikely() annotations since those should have some evidence
of benefit behind it. Applying the same policy to __assume() usage would
help ensure there is sufficient justification for adding and maintaining
such annotations, especially if they turn out to cause problems later.
Not sure if there should be a format standard like exists for SAFETY
comments but something is better than nothing.
Cheers,
Nathan
next prev parent reply other threads:[~2025-09-11 20:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 15:12 [PATCH 0/3] s390: Fix and optimize __flogr() inline assembly Heiko Carstens
2025-09-10 15:12 ` [PATCH 1/3] Compiler Attributes: Add __assume macro Heiko Carstens
2025-09-11 1:32 ` Nathan Chancellor
2025-09-11 14:56 ` Heiko Carstens
2025-09-11 18:44 ` Nathan Chancellor
2025-09-11 19:04 ` Miguel Ojeda
2025-09-11 20:42 ` Nathan Chancellor [this message]
2025-09-11 18:56 ` Miguel Ojeda
2025-09-11 18:59 ` Miguel Ojeda
2025-09-12 10:25 ` Heiko Carstens
2025-09-10 15:12 ` [PATCH 2/3] s390/bitops: Limit return value range of __flogr() Heiko Carstens
2025-09-11 7:44 ` Juergen Christ
2025-09-11 13:24 ` kernel test robot
2025-09-10 15:12 ` [PATCH 3/3] s390/bitops: Remove volatile qualifier from flogr() inline assembly Heiko Carstens
2025-09-11 7:45 ` Juergen Christ
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250911204246.GA69679@ax162 \
--to=nathan@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jchrist@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=svens@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.