[cocci] Checking the search for a repeated condition check with SmPL

[cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

Hello,

I noticed another contribution by Dan Carpenter.
[PATCH] dm vdo slab-depot: delete unnecessary check
https://lore.kernel.org/lkml/16ffd614-48a9-42b8-961d-2dc8a69c48d6@moroto.mountain/
https://lkml.org/lkml/2024/2/9/397


I constructed another SmPL script variant accordingly.


@deletion@
binary operator bo;
constant c;
expression e;
identifier var;
@@
 if (
(    var bo c
&    e
)
 )
    return var;
 ... when != var
-if (e)
-   return var;


The known patch is generated then as expected for a source file
according to the software “Linux next-20240209”.

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> spatch …/Projekte/Coccinelle/janitor/delete_redundant_if_statement.cocci drivers/md/dm-vdo/slab-depot.c
…
@@ -4100,9 +4100,6 @@ static int allocate_components(struct sl
                };
        }

-       if (result != VDO_SUCCESS)
-               return result;
-
        slab_count = vdo_compute_slab_count(depot->first_block, depot->last_block,
                                            depot->slab_size_shift);
        if (thread_config->physical_zone_count > slab_count) {



I tried also the following SmPL script variant out together with
the software combination “Coccinelle 1.1.1-00676-g99513ec1”.


@deletion2@
binary operator bo;
constant c;
expression e;
identifier var;
@@
 if (var bo c)
    return var;
 ... when != var
-if (var bo c)
-   return var;


I wonder then why no patch is generated by the corresponding test.

Regards,
Markus

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

> @deletion@
> binary operator bo;
> constant c;
> expression e;
> identifier var;
> @@
>  if (
> (    var bo c
> &    e
> )
>  )
>     return var;
>  ... when != var
> -if (e)
> -   return var;

This script example for the semantic patch language contains a bit of
duplicate SmPL code.

Test result:
Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement.cocci
…
real    0m1,046s
user    0m0,969s
sys     0m0,055s



I got into the mood to check also
how good the following SmPL script variants would work.

@succinct_deletion@
binary operator bo;
constant c;
identifier var;
statement s;
@@
( if (var bo c) return var;
& s
)
 ... when != var
- s



Another test result:
Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch --timeout 123 drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement3.cocci
…
timeout (we abort)
Fatal error: exception Coccinelle_modules.Common.Timeout

real    2m5,419s
user    2m2,733s
sys     0m0,719s



@specific_deletion@
identifier var;
statement s;
@@
( if (var != VDO_SUCCESS)
     return var;
& s
)
 ... when != var
- s


Another test result:
Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch --timeout 123 drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement4.cocci
…
timeout (we abort)
Fatal error: exception Coccinelle_modules.Common.Timeout

real    2m5,305s
user    2m3,025s
sys     0m0,547s



Will such data achieve any software improvements?

Regards,
Markus

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]



On Sun, 11 Feb 2024, Markus Elfring wrote:

> > @deletion@
> > binary operator bo;
> > constant c;
> > expression e;
> > identifier var;
> > @@
> >  if (
> > (    var bo c
> > &    e
> > )
> >  )
> >     return var;
> >  ... when != var
> > -if (e)
> > -   return var;
>
> This script example for the semantic patch language contains a bit of
> duplicate SmPL code.
>
> Test result:
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement.cocci
> …
> real    0m1,046s
> user    0m0,969s
> sys     0m0,055s
>
>
>
> I got into the mood to check also
> how good the following SmPL script variants would work.
>
> @succinct_deletion@
> binary operator bo;
> constant c;
> identifier var;
> statement s;
> @@
> ( if (var bo c) return var;
> & s
> )
>  ... when != var
> - s
>
>
>
> Another test result:
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch --timeout 123 drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement3.cocci
> …
> timeout (we abort)
> Fatal error: exception Coccinelle_modules.Common.Timeout
>
> real    2m5,419s
> user    2m2,733s
> sys     0m0,719s
>
>
>
> @specific_deletion@
> identifier var;
> statement s;
> @@
> ( if (var != VDO_SUCCESS)
>      return var;
> & s
> )
>  ... when != var
> - s
>
>
> Another test result:
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch --timeout 123 drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement4.cocci
> …
> timeout (we abort)
> Fatal error: exception Coccinelle_modules.Common.Timeout
>
> real    2m5,305s
> user    2m3,025s
> sys     0m0,547s
>
>
>
> Will such data achieve any software improvements?

Since you haven't provided any test data and since the file that you
reference is not part of Linux 6.8-rc3, I'm not going to look into this.

First, please use --debug --verbose-ctl-engine and see if you can figure
out the answer yourself from the output.

If you can't figure out the answer and you want to pursue this, please
send back one email that includes both the esmntic patch above and a
single function that illustrates the problem.

julia

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

>> Will such data achieve any software improvements?
>
> Since you haven't provided any test data and since the file that you
> reference is not part of Linux 6.8-rc3,

I referred to a source file from the software “Linux next-20240209”
which is obviously available.


> I'm not going to look into this.

I suggest to reconsider this response.


> First, please use --debug --verbose-ctl-engine and see if you can figure
> out the answer yourself from the output.

I hope that development interests will grow for better software run time characteristics.


> If you can't figure out the answer and you want to pursue this, please
> send back one email that includes both the esmntic patch above and a
> single function that illustrates the problem.

Would you become interested to extend software tests also together with
the attached two files?


Markus_Elfring@Sonne:…/Projekte/Coccinelle/janitor> time spatch ../Probe/slab-depot-excerpt-20240209.c delete_redundant_if_statement4.cocci
…
real    0m0,249s
user    0m0,221s
sys     0m0,018s


Regards,
Markus

[-- Attachment #2: delete_redundant_if_statement4.cocci --]
[-- Type: text/plain, Size: 122 bytes --]

@specific_deletion@
identifier var;
statement s;
@@
( if (var != VDO_SUCCESS)
     return var;
& s
)
 ... when != var
- s

[-- Attachment #3: slab-depot-excerpt-20240209.c --]
[-- Type: text/x-csrc, Size: 1951 bytes --]

// SPDX-License-Identifier: GPL-2.0-only
/*
 * Copyright 2023 Red Hat
 */
// See also:
// Contribution by Matthew Sakai from 2023-11-16
// https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/md/dm-vdo/slab-depot.c?id=789d98f7f5ec7f094d84ea28b63404ccfdb48a1f
//
// deleted part
static int allocate_components(struct slab_depot *depot,
			       struct partition *summary_partition)
{
	int result;
	zone_count_t zone;
	slab_count_t slab_count;
	u8 hint;
	u32 i;
	const struct thread_config *thread_config = &depot->vdo->thread_config;

	result = vdo_make_action_manager(depot->zone_count, get_allocator_thread_id,
					 thread_config->journal_thread, depot,
					 schedule_tail_block_commit,
					 depot->vdo, &depot->action_manager);
	if (result != VDO_SUCCESS)
		return result;

	depot->origin = depot->first_block;

	/* block size must be a multiple of entry size */
	BUILD_BUG_ON((VDO_BLOCK_SIZE % sizeof(struct slab_summary_entry)) != 0);

	depot->summary_origin = summary_partition->offset;
	depot->hint_shift = vdo_get_slab_summary_hint_shift(depot->slab_size_shift);
	result = uds_allocate(MAXIMUM_VDO_SLAB_SUMMARY_ENTRIES,
			      struct slab_summary_entry, __func__,
			      &depot->summary_entries);
	if (result != VDO_SUCCESS)
		return result;


	/* Initialize all the entries. */
	hint = compute_fullness_hint(depot, depot->slab_config.data_blocks);
	for (i = 0; i < MAXIMUM_VDO_SLAB_SUMMARY_ENTRIES; i++) {
		/*
		 * This default tail block offset must be reflected in
		 * slabJournal.c::read_slab_journal_tail().
		 */
		depot->summary_entries[i] = (struct slab_summary_entry) {
			.tail_block_offset = 0,
			.fullness_hint = hint,
			.load_ref_counts = false,
			.is_dirty = false,
		};
	}

	if (result != VDO_SUCCESS)
		return result;

	slab_count = vdo_compute_slab_count(depot->first_block, depot->last_block,
					    depot->slab_size_shift);
// deleted part

	return VDO_SUCCESS;
}
// deleted part

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]



On Sun, 11 Feb 2024, Markus Elfring wrote:

> >> Will such data achieve any software improvements?
> >
> > Since you haven't provided any test data and since the file that you
> > reference is not part of Linux 6.8-rc3,
>
> I referred to a source file from the software “Linux next-20240209”
> which is obviously available.
>
>
> > I'm not going to look into this.
>
> I suggest to reconsider this response.
>
>
> > First, please use --debug --verbose-ctl-engine and see if you can figure
> > out the answer yourself from the output.
>
> I hope that development interests will grow for better software run time characteristics.
>
>
> > If you can't figure out the answer and you want to pursue this, please
> > send back one email that includes both the esmntic patch above and a
> > single function that illustrates the problem.
>
> Would you become interested to extend software tests also together with
> the attached two files?

Thanks for providing the semantic patch and a small excerpt of C code in a
single email.

julia

>
>
> Markus_Elfring@Sonne:…/Projekte/Coccinelle/janitor> time spatch ../Probe/slab-depot-excerpt-20240209.c delete_redundant_if_statement4.cocci
> …
> real    0m0,249s
> user    0m0,221s
> sys     0m0,018s
>
>
> Regards,
> Markus
>

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

> I got into the mood to check also
> how good the following SmPL script variants would work

also together with the software combination “Coccinelle 1.1.1-00687-g0df3efff”.


> @succinct_deletion@
> binary operator bo;
> constant c;
> identifier var;
> statement s;
> @@
> ( if (var bo c) return var;
> & s
> )
>  ... when != var
> - s
>
>
>
> Another test result:

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement3.cocci
…
real    0m17,970s
user    0m17,754s
sys     0m0,080s



> @specific_deletion@
> identifier var;
> statement s;
> @@
> ( if (var != VDO_SUCCESS)
>      return var;
> & s
> )
>  ... when != var
> - s
>
>
> Another test result:

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement4.cocci
…
real    0m13,992s
user    0m13,348s
sys     0m0,071s


Which recent commits did improve the software situation for this issue?

Regards,
Markus

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]



On Thu, 15 Feb 2024, Markus Elfring wrote:

> > I got into the mood to check also
> > how good the following SmPL script variants would work
>
> also together with the software combination “Coccinelle 1.1.1-00687-g0df3efff”.
>
>
> > @succinct_deletion@
> > binary operator bo;
> > constant c;
> > identifier var;
> > statement s;
> > @@
> > ( if (var bo c) return var;
> > & s
> > )
> >  ... when != var
> > - s
> >
> >
> >
> > Another test result:
>
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement3.cocci
> …
> real    0m17,970s
> user    0m17,754s
> sys     0m0,080s
>
>
>
> > @specific_deletion@
> > identifier var;
> > statement s;
> > @@
> > ( if (var != VDO_SUCCESS)
> >      return var;
> > & s
> > )
> >  ... when != var
> > - s
> >
> >
> > Another test result:
>
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement4.cocci
> …
> real    0m13,992s
> user    0m13,348s
> sys     0m0,071s
>
>
> Which recent commits did improve the software situation for this issue?

The one on which you keep asking me to add the link to your email message.

But I had the impression that it would have the effect of making both of
your tests slower...

julia

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

> But I had the impression that it would have the effect of making both of
> your tests slower...

A known patch was finally generated also by these SmPL script variants
in a time frame which might be reasonable (for the affected source file).
I became curious how the corresponding software run time characteristics
will evolve further.

Regards,
Markus

Re: [cocci] Fixing the SmPL search for a bit of duplicate code

[Markus Elfring]

> I wonder then why no patch is generated by the corresponding test.

The clarification can be continued for the data processing by some scripts
of the semantic patch language also with the help of the following small
source code example.


// See also:
// Fix the search for a repeated condition check with SmPL
// 2024-02-10
// https://github.com/coccinelle/coccinelle/issues/352

int my_test_allocate_components(void)
{
	int result = x_allocate();
	if (result != X_SUCCESS)
		return result;
// placeholder
	if (result != X_SUCCESS)
		return result;
// placeholder
	return X_SUCCESS;
}


A patch is generated by two SmPL script variants where SmPL conjunctions
are applied together with metavariables of the type “expression” or “statement”.

Thus I wonder still why no diff output is produced by the following SmPL
script variant.


@deletion2@
binary operator bo;
constant c;
identifier var;
@@
 if (var bo c)
    return var;
 ... when != var
-if (var bo c)
-   return var;


Regards,
Markus

Re: [cocci] Fixing the SmPL search for a bit of duplicate code

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]



On Sat, 17 Feb 2024, Markus Elfring wrote:

> > I wonder then why no patch is generated by the corresponding test.
>
> The clarification can be continued for the data processing by some scripts
> of the semantic patch language also with the help of the following small
> source code example.
>
>
> // See also:
> // Fix the search for a repeated condition check with SmPL
> // 2024-02-10
> // https://github.com/coccinelle/coccinelle/issues/352
>
> int my_test_allocate_components(void)
> {
> 	int result = x_allocate();
> 	if (result != X_SUCCESS)
> 		return result;
> // placeholder
> 	if (result != X_SUCCESS)
> 		return result;
> // placeholder
> 	return X_SUCCESS;
> }
>
>
> A patch is generated by two SmPL script variants where SmPL conjunctions
> are applied together with metavariables of the type “expression” or “statement”.
>
> Thus I wonder still why no diff output is produced by the following SmPL
> script variant.
>
>
> @deletion2@
> binary operator bo;
> constant c;
> identifier var;
> @@
>  if (var bo c)
>     return var;
>  ... when != var
> -if (var bo c)
> -   return var;

Fixed incorrect handing of binary operators.  Thanks.

julia

Re: [cocci] Fixing the SmPL search for a bit of duplicate code

[Markus Elfring]

>> @deletion2@
>> binary operator bo;
>> constant c;
>> identifier var;
>> @@
>>  if (var bo c)
>>     return var;
>>  ... when != var
>> -if (var bo c)
>> -   return var;
>
> Fixed incorrect handing of binary operators.

Is it interesting that such an open issue was not tackled before?

Thanks for your corresponding contribution.

binops and assignops need to be stripped before being put into metavariables
2024-02-17
https://gitlab.inria.fr/coccinelle/coccinelle/-/commit/cf3ea16c48751708ab468919c736acb06f7e1ff7
https://github.com/coccinelle/coccinelle/commit/cf3ea16c48751708ab468919c736acb06f7e1ff7


Will any collateral evolution become more appealing accordingly?

Regards,
Markus

Re: [cocci] Fixing the SmPL search for a bit of duplicate code

[Markus Elfring]

> binops and assignops need to be stripped before being put into metavariables
> 2024-02-17
> https://gitlab.inria.fr/coccinelle/coccinelle/-/commit/cf3ea16c48751708ab468919c736acb06f7e1ff7

How do you think about to explain the influence of the mentioned “stripping”
on desired data processing a bit more?

Applications of the metavariable type “binary operator” were occasionally
discussed before.

Another example topic:
Complete support for data processing with binary operators
2020-09-29
https://github.com/coccinelle/coccinelle/issues/227

Regards,
Markus

Re: [cocci] Fixing the SmPL search for a bit of duplicate code

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]



On Sun, 18 Feb 2024, Markus Elfring wrote:

> > binops and assignops need to be stripped before being put into metavariables
> > 2024-02-17
> > https://gitlab.inria.fr/coccinelle/coccinelle/-/commit/cf3ea16c48751708ab468919c736acb06f7e1ff7
>
> How do you think about to explain the influence of the mentioned “stripping”
> on desired data processing a bit more?

Stripping removes line and column numbers and allow metavariables bound in
two different places to be considered to have consistent values.

>
> Applications of the metavariable type “binary operator” were occasionally
> discussed before.

But probably no one ever tried two matches of the same one.

julia

> Another example topic:
> Complete support for data processing with binary operators
> 2020-09-29
> https://github.com/coccinelle/coccinelle/issues/227
>
> Regards,
> Markus
>

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

> I became curious how the corresponding software run time characteristics
> will evolve further.

Another contribution was published yesterday:
binops and assignops need to be stripped before being put into metavariables

Thus data processing can be measured after such a development progress
also together with the software combination “Coccinelle 1.1.1-00736-gcf3ea16c”
for the following SmPL script variant.


@deletion2@
binary operator bo;
constant c;
identifier var;
@@
 if (var bo c)
    return var;
 ... when != var
-if (var bo c)
-   return var;


Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> git checkout next-20240209 && time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement2.cocci
…
@@ -4100,9 +4100,6 @@ static int allocate_components(struct sl
…
real    0m1,211s
user    0m0,981s
sys     0m0,095s


* Can such a test result trigger any development concerns for wider applications
  of SmPL conjunctions?
  https://lore.kernel.org/cocci/01fe8b37-9fff-4137-818c-8a851ce588a3@web.de/

* How will comparisons of source code search and transformation algorithms
  evolve further?


Regards,
Markus

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]



On Sun, 18 Feb 2024, Markus Elfring wrote:

> > I became curious how the corresponding software run time characteristics
> > will evolve further.
>
> Another contribution was published yesterday:
> binops and assignops need to be stripped before being put into metavariables
>
> Thus data processing can be measured after such a development progress
> also together with the software combination “Coccinelle 1.1.1-00736-gcf3ea16c”
> for the following SmPL script variant.
>
>
> @deletion2@
> binary operator bo;
> constant c;
> identifier var;
> @@
>  if (var bo c)
>     return var;
>  ... when != var
> -if (var bo c)
> -   return var;
>
>
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> git checkout next-20240209 && time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement2.cocci
> …
> @@ -4100,9 +4100,6 @@ static int allocate_components(struct sl
> …
> real    0m1,211s
> user    0m0,981s
> sys     0m0,095s


I don't understand what is the issue.  If it takes more times than before,
then post the old running time too.  If it takes a little more time than
before, then that's normal, because when the match succeeds, it does more
work.

julia

>
>
> * Can such a test result trigger any development concerns for wider applications
>   of SmPL conjunctions?
>   https://lore.kernel.org/cocci/01fe8b37-9fff-4137-818c-8a851ce588a3@web.de/
>
> * How will comparisons of source code search and transformation algorithms
>   evolve further?
>
>
> Regards,
> Markus
>

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

>> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> git checkout next-20240209 && time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement2.cocci
>> …
>> @@ -4100,9 +4100,6 @@ static int allocate_components(struct sl
>> …
>> real    0m1,211s
>> user    0m0,981s
>> sys     0m0,095s
>
>
> I don't understand what is the issue.  If it takes more times than before,
> then post the old running time too.

Another test result:
Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> git checkout next-20240209 && time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement.cocci
…
real    0m1,065s
user    0m0,957s
sys     0m0,079s



You can take another look at previous measurement examples.
(The numbers will probably be different in other test environments.)

Repetition for your convenience:
https://lore.kernel.org/cocci/4bd9de70-de02-4fea-9d41-095304edf4fe@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2024-02/msg00063.html
+ delete_redundant_if_statement3.cocci:
  real    0m17,970s
  user    0m17,754s
  sys     0m0,080s

+ delete_redundant_if_statement4.cocci:
  real    0m13,992s
  user    0m13,348s
  sys     0m0,071s


> If it takes a little more time than before,

The application of a higher level metavariable type “statement” for an SmPL conjunction
makes a significant difference here.


> then that's normal, because when the match succeeds, it does more work.

It seems to be unclear so far how much extra efforts would be reasonable.

Regards,
Markus

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Julia Lawall]

Coccinelle's ... is based on CTL AU, and as such works bottom up.

Accordingly, the following semantic patch is quite slow:

@@
binary operator bo;
constant c;
identifier var;
statement stmt;
@@
( if (var bo c) return var;
& stmt
)
 ... when != var
- stmt

And the following semantic patch is quite fast:

@@
binary operator bo;
constant c;
identifier var;
statement stmt;
@@
stmt
 ... when != var
( if (var bo c) return var;
&
- stmt
)

In the former case, it first matches stmt at the end of the semantic
patch, that can be anything.  In the latter case, it first matches the if,
then binds stmt, and then can easily recognize stmt earlier in the code.

There will be no changes in this respect.

The best solution is to just provide Coccinelle with as much information
as possible, and don't see to save characters in a file that is anyway
quite small.

julia

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

> Coccinelle's ... is based on CTL AU, and as such works bottom up.

I would appreciate further clarification for such information.
To which computation tree logic variant do you refer here for the handling of
SmPL ellipses?
(Can your technology “CTL-VW” influence the discussed data processing any more?)


> Accordingly, the following semantic patch is quite slow:
>
> @@
> binary operator bo;
> constant c;
> identifier var;
> statement stmt;
> @@
> ( if (var bo c) return var;
> & stmt
> )
>  ... when != var
> - stmt

I find your acknowledgement interesting for further development considerations.


> And the following semantic patch is quite fast:
>
> @@
> binary operator bo;
> constant c;
> identifier var;
> statement stmt;
> @@
> stmt
>  ... when != var
> ( if (var bo c) return var;
> &
> - stmt
> )
>
> In the former case, it first matches stmt at the end of the semantic patch,
> that can be anything.

I wonder about this SmPL code interpretation.


> In the latter case, it first matches the if, then binds stmt,
> and then can easily recognize stmt earlier in the code.

I would expect so far that the presented first SmPL script variant
should be evaluated in this direction.
Do we stumble on another communication difficulty around safer and more efficient
applications of the semantic patch language (including mentioned conjunctions)?


> There will be no changes in this respect.

I assume that circumstances can evolve in ways which might make
corresponding adjustments more feasible.

Regards,
Markus

Re: [cocci] Fixing the SmPL search for a bit of duplicate code

[Markus Elfring]

> Will any collateral evolution become more appealing accordingly?

How good does the next contribution fit into the discussed development story?

account for the fact that binops and assignops are now stripped
2023-02-18
https://gitlab.inria.fr/coccinelle/coccinelle/-/commit/b916699c924986392e876d30f0b838602fdd9ec1
https://github.com/coccinelle/coccinelle/commit/b916699c924986392e876d30f0b838602fdd9ec1


Which adjustments will become more interesting?

Regards,
Markus

Re: [cocci] Fixing the SmPL search for a bit of duplicate code

[Julia Lawall]

On Sun, 18 Feb 2024, Markus Elfring wrote:

> > Will any collateral evolution become more appealing accordingly?
>
> How good does the next contribution fit into the discussed development story?

Not at all.

julia

>
> account for the fact that binops and assignops are now stripped
> 2023-02-18
> https://gitlab.inria.fr/coccinelle/coccinelle/-/commit/b916699c924986392e876d30f0b838602fdd9ec1
> https://github.com/coccinelle/coccinelle/commit/b916699c924986392e876d30f0b838602fdd9ec1
>
>
> Which adjustments will become more interesting?
>
> Regards,
> Markus
>

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

> In the former case, it first matches stmt at the end of the semantic patch,
> that can be anything.  In the latter case, it first matches the if,
> then binds stmt, and then can easily recognize stmt earlier in the code.

How will the chances evolve to achieve consensus on the desired
evaluation order for the shown source code search and transformation code
according to the semantic patch language?


> There will be no changes in this respect.

There are several open issues in some waiting queues with the potential
to improve the development and data processing situation considerably.

Regards,
Markus

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Julia Lawall]

On Mon, 19 Feb 2024, Markus Elfring wrote:

> > In the former case, it first matches stmt at the end of the semantic patch,
> > that can be anything.  In the latter case, it first matches the if,
> > then binds stmt, and then can easily recognize stmt earlier in the code.
>
> How will the chances evolve to achieve consensus on the desired
> evaluation order for the shown source code search and transformation code
> according to the semantic patch language?

We are not going to change the entire underpinnings of Coccinelle so that
you can have the pleasure of saving 10 characters.

julia

>
>
> > There will be no changes in this respect.
>
> There are several open issues in some waiting queues with the potential
> to improve the development and data processing situation considerably.
>
> Regards,
> Markus
>

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

>> How will the chances evolve to achieve consensus on the desired
>> evaluation order for the shown source code search and transformation code
>> according to the semantic patch language?
>
> We are not going to change the entire underpinnings of Coccinelle

I hope that interests can grow to take another look at affected
implementation details.


> so that you can have the pleasure of saving 10 characters.

It seems that your feedback indicates general communication challenges
for the clarification of desirable data processing approaches.
Can any other contributors help more to adjust involved development concerns?

Regards,
Markus

Re: [cocci] Checking the search for a repeated condition check with SmPL

[Markus Elfring]

Another contribution was published yesterday:
account for the fact that binops and assignops are now stripped

Thus data processing can be measured once more after such a bit of development progress
also together with the software combination “Coccinelle 1.1.1-00739-g68c580f1”
for the following SmPL script variants.


> Accordingly, the following semantic patch is quite slow:
>
> @@
> binary operator bo;
> constant c;
> identifier var;
> statement stmt;
> @@
> ( if (var bo c) return var;
> & stmt
> )
>  ... when != var
> - stmt

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> git checkout next-20240209 && time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement3.cocci
…
real    0m16,386s
user    0m16,306s
sys     0m0,056s


> And the following semantic patch is quite fast:
>
> @@
> binary operator bo;
> constant c;
> identifier var;
> statement stmt;
> @@
> stmt
>  ... when != var
> ( if (var bo c) return var;
> &
> - stmt
> )

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> git checkout next-20240209 && time spatch drivers/md/dm-vdo/slab-depot.c …/Projekte/Coccinelle/janitor/delete_redundant_if_statement-by_Julia-20240218.cocci
…
real    0m47,888s
user    0m47,238s
sys     0m0,304s


> In the former case, it first matches stmt at the end of the semantic
> patch, that can be anything.  In the latter case, it first matches the if,
> then binds stmt, and then can easily recognize stmt earlier in the code.
>
> There will be no changes in this respect.

Which evaluation order for the shown source code search and transformation code
(according to the semantic patch language) will become more desirable finally?

Will development interests grow to reduce the software run time differences
(according to the demonstrated application of a higher level metavariable type “statement”)
for an SmPL conjunction considerably?

Regards,
Markus