New trivial `lincomb` nodes

[mfasi]

One thing I noticed by looking at the generated C and Julia code is that we now have a number of new trivial lincomb nodes, such as

    X ← + α × A + 0 × B

which should really be

    X ← + α × A             (a)

or

X ← 1 × A

which is just a copy and should be removed. In fact, nodes of the form (a) could also be removed by pushing α to the corresponding coefficient(s) of subsequent lincombs, although this seems a bit messier to do.

Originally posted by @mfasi in #77 (comment)

[jarlebring]

This type of optimization should not be done in the code generation in my opinion. A user can always run compress_trivial! before calling gen_code and those cases will be removed. It can be handled at graph-level. I think we get cleaner code-generation code if we see the code generator as being a bit stupid. Code generation philosophy: "Generate code for exactly this graph".

• compress_trivial! handles the first case (zero coeffs).
• Not sure about the second case (single-term lincomb with coeff is one).
• Third case (single-term lincomb with non-one + push lincombs) is indeed a bit messier, and depends on how X is used elsewhere, e.g. if it comes as :mul. Maybe it's a special case of if X is computed as lincomb and X is only used in a lincomb, then the two lincombs can be merged.

[mfasi]

I'll have a look and see if I can update compress_trivial! to handle the "copy" case.

I did remove terms with 0 coefficient in the C generator, but I can go roll back easily on that – I'd just need to remove

GraphMatFun.jl/src/code_gen/gen_c_code.jl

Lines 496 to 498 in e4d6efd

	if v == 0
	continue
	end

[jarlebring]

I would be in favor of rolling that back, also for consistency with other generators. Maybe we first check that compress_trivial! actually does what I said. My memory is not perfect 🤯