Coccinelle archive mirror
 help / color / mirror / Atom feed

From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Coccinelle ML <cocci@inria.fr>
Subject: [cocci] Optimizing *.cocci rules by concat'ing them
Date: Thu, 01 Sep 2022 17:00:05 +0200	[thread overview]
Message-ID: <220901.8635dbjfko.gmgdl@evledraar.gmail.com> (raw)

Are there reasons for why $subject is a generally bad idea, i.e. given a
set of *.cocci rules in a directory instead of something like:

	for c in cocci/*.cocci
	do
		spatch --sp-file $c --patch . *.c
	done

Doing:

	cat cocci/*.cocci >ALL.cocci
	spatch --sp-file ALL.cocci --patch . *.c

I'm aware that rules in general may rely on previous transformations,
such that the 3rd rule in a file might not fire unless the other 2 have
previously changed the code.

But aside from any such undeclared dependencies, which surely I'll have
trouble with either way. I.e. I'd get to the 2nd rule in A.cocci, apply
that to my sources, and only then on a second run would the 1st rule in
B.cocci fire, but it should have been in A.cocci to begin with, and
depending on the 2nd rule in that file.

Are there reasons for why this is a Bad Idea?

The motivation here (and this is probably burying the lede) is that I
implemented a "spatchcache", which can cache previous runs of "spatch"
in a local Redis (or with a custom command, if you don't have Redis, I
started out with a dumb FS-based cache).

It uses the approach of piggy-backing on GCC and Clang's ability to dump
a full list of all the files that a given *.c file depends on.

This is usually used to drive better incremental "make" support, but I'm
(ab)using it to implement an "spatchcache". If the hash of a the target
file *and* everything it depends on *and* spatch's path, flags etc. is
the same I can cache the output of "spatch".

See [1] for a series to implement this for git.git. I'd previously mused
on this list in [2] about this approach (but hadn't finished it up until
now).

But even then git's fairly slow in running "make coccicheck", and of
course it does nothing to speed up an initial run. So concat'ing the
*.cocci files we use seems like a viable option. But I thought I'd ask
first in case I'm running into somewell-known caveat.

Thanks!

1. https://lore.kernel.org/git/cover-v2-0.9-00000000000-20220831T205130Z-avarab@gmail.com/
2. https://lore.kernel.org/cocci/211116.86lf1op65q.gmgdl@evledraar.gmail.com/

next             reply	other threads:[~2022-09-01 15:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01 15:00 Ævar Arnfjörð Bjarmason [this message]
2022-09-01 15:19 ` [cocci] Optimizing *.cocci rules by concat'ing them Julia Lawall
2022-09-01 18:12 ` [cocci] Checking consequences from concatenation of SmPL rules Markus Elfring

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=220901.8635dbjfko.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=cocci@inria.fr \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).