[PATCH] fix expansion cost of pure functions

[PATCH] fix expansion cost of pure functions

[Luc Van Oostenryck]

Expansion cost of an expression should be a monotonically
increasing function of its sub-expressions.

Here, for the costs of calling a pure function, the costs is
reset to zero (wich is used when the expression expand to
a constant/to test if the expression is a constant or not).

Fix this by setting the cost as the total expansion cost of
all the arguments plus one for the function itself.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
 expand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/expand.c b/expand.c
index 7af12707e..738c79c51 100644
--- a/expand.c
+++ b/expand.c
@@ -796,7 +796,7 @@ static int expand_symbol_call(struct expression *expr, int cost)
 		return ctype->op->expand(expr, cost);
 
 	if (ctype->ctype.modifiers & MOD_PURE)
-		return 0;
+		return cost + 1;
 
 	return SIDE_EFFECTS;
 }
-- 
2.11.0

Re: [PATCH] fix expansion cost of pure functions

[Christopher Li]

On Thu, Feb 16, 2017 at 11:45 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> Expansion cost of an expression should be a monotonically
> increasing function of its sub-expressions.
>
> Here, for the costs of calling a pure function, the costs is
> reset to zero (wich is used when the expression expand to
> a constant/to test if the expression is a constant or not).
>
> Fix this by setting the cost as the total expansion cost of
> all the arguments plus one for the function itself.

I am not sure about this one, adding CC to Linus.

Currently pure function and constant function both share MOD_PURE.
If the function has attribute "pure" or "constant", then the user is
telling the compiler this function does not have side effects.

I think dropping to zero has some thing to do with get rid of
the side effect cost. So it possible the cost can be dropping.
But maybe it shouldn't drop to zero.

Chris

Re: [PATCH] fix expansion cost of pure functions

[Linus Torvalds]

On Wed, Feb 22, 2017 at 3:57 PM, Christopher Li <sparse@chrisli.org> wrote:
>
> I think dropping to zero has some thing to do with get rid of
> the side effect cost. So it possible the cost can be dropping.

No, I think the zero is just a bug, introduced in commit 8376ab091a
("sparse: Fix __builtin_safe_p for pure and const functions").

I might be missing something, but I think Luc's patch is fine.

              Linus

Re: [PATCH] fix expansion cost of pure functions

[Christopher Li]

On Thu, Feb 23, 2017 at 9:01 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Feb 22, 2017 at 3:57 PM, Christopher Li <sparse@chrisli.org> wrote:
>>
>> I think dropping to zero has some thing to do with get rid of
>> the side effect cost. So it possible the cost can be dropping.
>
> No, I think the zero is just a bug, introduced in commit 8376ab091a
> ("sparse: Fix __builtin_safe_p for pure and const functions").
>
> I might be missing something, but I think Luc's patch is fine.
>
>               Linus

Re: [PATCH] fix expansion cost of pure functions

[Christopher Li]

On Thu, Feb 23, 2017 at 9:01 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> No, I think the zero is just a bug, introduced in commit 8376ab091a
> ("sparse: Fix __builtin_safe_p for pure and const functions").
>
> I might be missing something, but I think Luc's patch is fine.

Thanks for the insight. I will apply it.

Chris