id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
4129	Inefficient array code generation	Rüdiger Franke	Lennart Ochel	"See the following example that just was added to the testsuite:
{{{#!mo
model AliasArrayTest
  Real[3,3] A = {{t, 2, 3}, {4, t, 6}, {7, 8, t}}; // RefArrayDim2
  Real[:] b = (t + 1) * {1, 2, 3};
  Real t = time;
  output Real[3] x;
equation
  x = Modelica.Math.Matrices.solve(A, b);
  annotation(experiment(StopTime = 0));
end AliasArrayTest;
}}}

OpenModelica generates very inefficient simcode:
{{{#!mo
x[1] = Modelica.Math.Matrices.solve({{A[3,3], 2.0, 3.0}, {4.0, A[3,3], 6.0}, {7.0, 8.0, A[3,3]}}, {b[1], b[2], b[3]})[1];
x[2] = Modelica.Math.Matrices.solve({{A[3,3], 2.0, 3.0}, {4.0, A[3,3], 6.0}, {7.0, 8.0, A[3,3]}}, {b[1], b[2], b[3]})[2];
x[3] = Modelica.Math.Matrices.solve({{A[3,3], 2.0, 3.0}, {4.0, A[3,3], 6.0}, {7.0, 8.0, A[3,3]}}, {b[1], b[2], b[3]})[3];
}}}

Meaning the equation system is solved once for each element of the solution vector and two temporary arrays are created for each call to solve.

The generated simcode should read:
{{{#!mo
x = Modelica.Math.Matrices.solve(A, b);
}}}

A similar thing was solved recently for tuples, see [https://github.com/OpenModelica/OMCompiler/commit/1692f27c86cdbda67a641df8800ed2be35cb29a1 BackendDAE.ASSIGN can hold tuples on lhs].

This example can be simplified manually in the generated Cpp code (C as well I think). Then also the storage order of RefArray plays a role, see [https://github.com/OpenModelica/OMCompiler/commit/e657602228b40dc9eb103833607fc983e5d50ed2 Unify storage order of RefArray]."	defect	new	high		Backend				Volker Waurich Vitalij Ruge Willi Braun