cgen: remove unused code generated for unwrapping temp var from callexpr (detect unused return value from CallExpr)

[felipensp]

This PR adds a flag on ast.CallExpr to state about its return value is used. Using such information we can handle better the temporary storage for returning values or not.

_{Huly®: V_0.6-21216}

[felipensp]

About 40 unused option tmp var data access removed from .c file of cmd/v

+  (*(int*)_t8.data);
+  (*(int*)_t9.data);
+  (*(int*)_t10.data);
+  (*(int*)_t11.data);
+  (*(int*)_t12.data);
+  (*(int*)_t13.data);
+  (*(int*)_t15.data);
+  (*(int*)_t16.data);

[spytheman]

Why are they marked with +, instead of -?

[felipensp]

Why are they marked with +, instead of -?

My diff -uwp new old command with misordered file arg. 👍🏻

[spytheman]

oh, ok

[spytheman]

Is there a performance impact?

[StunxFS]

I think this could be handled if the checker warned for every expression whose value had not been used, and recommended using _ = instead, so the codegen would generate (void)<expr>.

[felipensp]

I think this could be handled if the checker warned for every expression whose value had not been used, and recommended using _ = instead, so the codegen would generate (void)<expr>.

Yes, with this new flag is_return_used we can provide new compiler features/optimizations.

[felipensp]

Is there a performance impact?

I haven't noticed perf impacts.

[StunxFS]

I think this could be handled if the checker warned for every expression whose value had not been used, and recommended using _ = instead, so the codegen would generate (void)<expr>.

Yes, with this new flag is_return_used we can provide new compiler features/optimizations.

@felipensp What I have in mind does not require .is_return_used, it would be enough for the checker, when checking a list of statements, to check if the last statement is of a type other than void, if so (and if it is not the last statement of an if or match block) that the checker warned about.

[felipensp]

I'm working on it to set the flag about value usage in parse-time... removing the checker sets right now.

[spytheman]

I'm working on it to set the flag about value usage in parse-time... removing the checker sets right now.

You can not do it reliably in the parser, since it does not have the complete type info.

For example, you can have a call to a function declared in another .v file in the same module, that may not be parsed yet, and you will not know if the current call expression returns something or not.

In the checker, since all the .v files are already parsed, the table is filled with all the symbols declared in all of them, and you so you know for sure what every call expression refers to.

[felipensp]

I'm working on it to set the flag about value usage in parse-time... removing the checker sets right now.

You can not do it reliably in the parser, since it does not have the complete type info.

For example, you can have a call to a function declared in another .v file in the same module, that may not be parsed yet, and you will not know if the current call expression returns something or not.

In the checker, since all the .v files are already parsed, the table is filled with all the symbols declared in all of them, and you so you know for sure what every call expression refers to.

I think we're talking about different thing. I mean about knowing wether the value is being used or not in the code, not about expr types checking. This is my objective here.

[StunxFS]

I'm working on it to set the flag about value usage in parse-time... removing the checker sets right now.

You can not do it reliably in the parser, since it does not have the complete type info.
For example, you can have a call to a function declared in another .v file in the same module, that may not be parsed yet, and you will not know if the current call expression returns something or not.
In the checker, since all the .v files are already parsed, the table is filled with all the symbols declared in all of them, and you so you know for sure what every call expression refers to.

I think we're talking about different thing. I mean about knowing wether the value is being used or not in the code, not about expr types checking. This is my objective here.

And how do you know if the type of the returned value is other than void?

[felipensp]

I'm working on it to set the flag about value usage in parse-time... removing the checker sets right now.

You can not do it reliably in the parser, since it does not have the complete type info.
For example, you can have a call to a function declared in another .v file in the same module, that may not be parsed yet, and you will not know if the current call expression returns something or not.
In the checker, since all the .v files are already parsed, the table is filled with all the symbols declared in all of them, and you so you know for sure what every call expression refers to.

I think we're talking about different thing. I mean about knowing wether the value is being used or not in the code, not about expr types checking. This is my objective here.

And how do you know if the type of the returned value is other than void?

My goal is not check the returned type but if the possible return value is used or not.

[spytheman]

If you have just f() in some place, you do not know if f() returned something, and that is being ignored, or if did not return anything at all, without knowing the full declaration of fn f() and the return type.

[spytheman]

I guess for the purpose of code generation, just having a plain f(), instead of a := f() or g(f()), is enough to know that the potential returned value is ignored, but that is not the case for using that information in more complex ways in the checker.

(except for x := if cond { f() } else { g() }, or match expressions, or default values in or blocks)

[spytheman]

Anyway, I did some performance checks, and there is not indeed a perceivable performance difference between the change here and on master, and the generated code is cleaner here.

Excellent work.