Re: [cocci] [PATCH 01/36] coccinelle: misc: add cond_return_no_effect.cocci

>> =E2=80=A6
>>> +++ b/scripts/coccinelle/misc/cond_return_no_effect.cocci
>>> @@ -0,0 +1,121 @@
>> =E2=80=A6
>>> +@depends on patch@
>>> +local idexpression ret;
>>> +expression E;
>>> +binary operator cmp =3D {<, <=3D, >, >=3D, =3D=3D, !=3D};
>>> +constant C;
>>> +@@
>>> +-	ret =3D E;
>>> +-	if (\(ret \| !ret \| ret cmp C\))
>>> +-		return ret;
>>> +-	return ret;
>>> ++	return E;
>>> +
>>> +@depends on patch@
>>> +idexpression ret;
>>> +binary operator cmp =3D {<, <=3D, >, >=3D, =3D=3D, !=3D};
>>> +constant C;
>>> +@@
>>> +-	if (\(ret \| !ret \| ret cmp C\))
>>> +-		return ret;
>>> +	return ret;
>> =E2=80=A6
>>
>> How do you think about to combine such transformation rules
>> by using an SmPL disjunction?
>=20
> I see no benefit to doing that.

Can software run time characteristics be influenced in desirable direction=
s
for such an use case?


>                                  In particular, the patterns search for
> some code in common, but from different places, since one starts with an
> assignment and the other starts with an if (that is common to both).

Would this implementation detail become interesting for corresponding refi=
nements?

Regards,
Markus