All of lore.kernel.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@rivosinc.com>
To: linux-sparse@vger.kernel.org, Kito Cheng <kito.cheng@gmail.com>,
	linux-riscv@lists.infradead.org, mkl@pengutronix.de,
	aurelien@aurel32.net,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH v1 0/6] RISC-V -march handling improvements
Date: Fri,  1 Apr 2022 22:00:35 -0700	[thread overview]
Message-ID: <20220402050041.21302-1-palmer@rivosinc.com> (raw)

As pointed out recently [1], sparse is parsing -march on RISC-V in order
to obtain the default set of preprocessor macros to use.  Back when this
was written ISA string was a simple affair, but these days it's a lot
more complicated.  It's going to be a big chunk of work to get a proper
ISA string parser into sparse, but we can at least fix the breakages for
the subset of legal ISA strings that Linux currently uses (and are
breaking users).

This patch set does three things:

* Stops die()ing on unknown ISA strings, unless the user has passed
  -Wsparse-error.  This prints a warning and guesses at the macros to
  use, which is probably fine for Linux.
* Cleans up some of the differences between GCC's -march parsing and
  sparse's.  None of this should really matter for Linux, as GCC will
  blow up on bad ISA strings, but it just seemed worth doing when I was
  in there.
* Adds support for the Zicsr and Zifencei extensions, which were
  recently enabled.  With these the unknown ISA string warning goes away
  for Linux builds.

They're all sort of independent (and happen in this order), but they're
all touching the same code so I'm just sending it as a series.  It's my
first time touching sparse.

I've poked around with the first patch on its own and it seems to
largely work as expected: I'm still getting a bunch of sparse-related
warnings when I turn on sparse in my builds, but at least I don't get an
error (after updating to a binutils that supports the new arguments, so
Linux detects them).  I tried CF="-Wsparse-error", which also behaves as
expected (that trinary boolean tripped me up for a bit).

The first patch alone should be a sufficient band-aid for systems that
are actively broken right now, the rest are cleanups -- these may be
necessary to get the RISC-V port sparse-clean, but that's a WIP so there
might be more.  I'm going to play around with that, but just looking at
the volume of spew it's probably going to take a while.  I gave these
patches a bit of testing one-by-one, but not nearly as much as the
first.

I just spun up a sparse repo [2] at kernel.org, these are on the riscv
branch if that helps for anyone.  I've also started messing around with
parsing a few more of the multi-letter extensions, but there's so much
coupling I got fed up -- it's on riscv-wip, but I definitely don't like
that last patch.  I figured it's better to send out these bits, as they
look solid to me and builds are broken.  The new stuff (B, K, and V) are
all in GCC-12 anyway, so we have a bit of time before they're useful.

[1]: https://lore.kernel.org/linux-sparse/mhng-c280d48c-477d-4589-baee-255c774b5a51@palmer-mbp2014/T/#maef705f448e4a1f12d853c0d8bc756f037ce1ce0
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/palmer/sparse.git



WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@rivosinc.com>
To: linux-sparse@vger.kernel.org, Kito Cheng <kito.cheng@gmail.com>,
	linux-riscv@lists.infradead.org, mkl@pengutronix.de,
	aurelien@aurel32.net,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH v1 0/6] RISC-V -march handling improvements
Date: Fri,  1 Apr 2022 22:00:35 -0700	[thread overview]
Message-ID: <20220402050041.21302-1-palmer@rivosinc.com> (raw)

As pointed out recently [1], sparse is parsing -march on RISC-V in order
to obtain the default set of preprocessor macros to use.  Back when this
was written ISA string was a simple affair, but these days it's a lot
more complicated.  It's going to be a big chunk of work to get a proper
ISA string parser into sparse, but we can at least fix the breakages for
the subset of legal ISA strings that Linux currently uses (and are
breaking users).

This patch set does three things:

* Stops die()ing on unknown ISA strings, unless the user has passed
  -Wsparse-error.  This prints a warning and guesses at the macros to
  use, which is probably fine for Linux.
* Cleans up some of the differences between GCC's -march parsing and
  sparse's.  None of this should really matter for Linux, as GCC will
  blow up on bad ISA strings, but it just seemed worth doing when I was
  in there.
* Adds support for the Zicsr and Zifencei extensions, which were
  recently enabled.  With these the unknown ISA string warning goes away
  for Linux builds.

They're all sort of independent (and happen in this order), but they're
all touching the same code so I'm just sending it as a series.  It's my
first time touching sparse.

I've poked around with the first patch on its own and it seems to
largely work as expected: I'm still getting a bunch of sparse-related
warnings when I turn on sparse in my builds, but at least I don't get an
error (after updating to a binutils that supports the new arguments, so
Linux detects them).  I tried CF="-Wsparse-error", which also behaves as
expected (that trinary boolean tripped me up for a bit).

The first patch alone should be a sufficient band-aid for systems that
are actively broken right now, the rest are cleanups -- these may be
necessary to get the RISC-V port sparse-clean, but that's a WIP so there
might be more.  I'm going to play around with that, but just looking at
the volume of spew it's probably going to take a while.  I gave these
patches a bit of testing one-by-one, but not nearly as much as the
first.

I just spun up a sparse repo [2] at kernel.org, these are on the riscv
branch if that helps for anyone.  I've also started messing around with
parsing a few more of the multi-letter extensions, but there's so much
coupling I got fed up -- it's on riscv-wip, but I definitely don't like
that last patch.  I figured it's better to send out these bits, as they
look solid to me and builds are broken.  The new stuff (B, K, and V) are
all in GCC-12 anyway, so we have a bit of time before they're useful.

[1]: https://lore.kernel.org/linux-sparse/mhng-c280d48c-477d-4589-baee-255c774b5a51@palmer-mbp2014/T/#maef705f448e4a1f12d853c0d8bc756f037ce1ce0
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/palmer/sparse.git



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

             reply	other threads:[~2022-04-02  5:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-02  5:00 Palmer Dabbelt [this message]
2022-04-02  5:00 ` [PATCH v1 0/6] RISC-V -march handling improvements Palmer Dabbelt
2022-04-02  5:00 ` [PATCH v1 1/6] RISC-V: Respect -Wsparse-error for -march errors Palmer Dabbelt
2022-04-02  5:00   ` Palmer Dabbelt
2022-05-21 21:46   ` Luc Van Oostenryck
2022-05-21 21:46     ` Luc Van Oostenryck
2022-04-02  5:00 ` [PATCH v1 2/6] RISC-V: Match GCC's semantics for multiple -march instances Palmer Dabbelt
2022-04-02  5:00   ` Palmer Dabbelt
2022-05-21 21:52   ` Luc Van Oostenryck
2022-05-21 21:52     ` Luc Van Oostenryck
2022-04-02  5:00 ` [PATCH v1 3/6] RISC-V: Remove the unimplemented ISA extensions Palmer Dabbelt
2022-04-02  5:00   ` Palmer Dabbelt
2022-05-21 22:05   ` Luc Van Oostenryck
2022-05-21 22:05     ` Luc Van Oostenryck
2022-04-02  5:00 ` [PATCH v1 4/6] RISC-V: Remove "g" from the extension list Palmer Dabbelt
2022-04-02  5:00   ` Palmer Dabbelt
2022-04-02  5:00 ` [PATCH v1 5/6] RISC-V: Add the Zicsr extension Palmer Dabbelt
2022-04-02  5:00   ` Palmer Dabbelt
2022-04-02  5:00 ` [PATCH v1 6/6] RISC-V: Add the Zifencei extension Palmer Dabbelt
2022-04-02  5:00   ` Palmer Dabbelt
2022-04-04 17:52 ` [PATCH v1 0/6] RISC-V -march handling improvements Marc Kleine-Budde
2022-04-04 17:52   ` Marc Kleine-Budde
2022-04-04 23:15   ` Palmer Dabbelt
2022-04-04 23:15     ` Palmer Dabbelt
2022-05-21 21:23 ` Luc Van Oostenryck
2022-05-21 21:23   ` Luc Van Oostenryck
2022-07-05 23:09   ` Palmer Dabbelt
2022-07-05 23:09     ` Palmer Dabbelt

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=20220402050041.21302-1-palmer@rivosinc.com \
    --to=palmer@rivosinc.com \
    --cc=aurelien@aurel32.net \
    --cc=kito.cheng@gmail.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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.