@David: I am sorry there was a misunderstanding with the example. You wrote
four lines of code to be able to replace two lines of code into a for-loop
of length 2, somewhere in a 1Bio line program where this pattern
coincidentally occured once in one generated instance. (In the next
instance, the "pattern" might not occur, so then you just added four
lines.) Also, it is unclear how you would implement in turn the code which
locates the line 200 and decides to replace it with the for-loop. Further,
you left unclear where to place this for-loop (in line 100 or line 200?),
both of which will lead to the wrong result in the generated program due to
false assumption on raise-conditions.
I think my initial question has been mis-correlated. I think so because we
drift into a discussion of speed and what is better and faster and
what-not. But this is not the question at all.
The setting is rather: I have a list of lengthy instructions. Think of a
grocery list. The most convenient language for me to write this grocery
list in is c++.
Now I don't care whether my doctor thinks I want to eat this all by myself
or on a weekly basis, and likes that thought or not. I just need to get the
groceries.
I can get them myself. In this case, it would mean I have to learn to
generate code of linear compile-complexity into assembly directly by myself.
I am not even interested in the compilation per se. I just need to be able
to evaluate the code as written.
I am equally fine with using an interpreted language or a different
language. But interpreters have the exact same issue: They refuse to start
computing a flat program code when the file containing it is too big.
So suppose I have a substitution of Taylor serieses into serieses and it
_does_ become chaotic after reordering of terms. That is after all the work
that the program does. That is what it is made for.
And now I just want some way to evaluate that formula once to tell me
whether y=f(x) yields y=0 for a particular value of x. This is as basic as
it gets.
I suppose the enablement of this capability is not in the scope of GCC. Is
there a name for this problem (evaluating lengthy list of compute
instructions/formulas)? Where should I look to find a solution to that
problem?
On Thu, Oct 19, 2023 at 6:03 PM David Brown <david@xxxxxxxxxxxxxxx> wrote:
> On 19/10/2023 17:11, Kai Song via Gcc-help wrote:
>
> (It can be helpful to include attributions when replying, so that it is
> clear who wrote what. Thus you should have this line included:)
>
> > On 19/10/2023 16:26, Jonathan Wakely via Gcc-help wrote:
>
>
> >> Nothing you have said actually explains why you can't refactor the
> >> code into utility functions that avoid doing everything in one huge
> >> function.
> >>
> >
> > Because there are no two pieces of code that are exactly identical. The
> > relative distance of two variables being involved into an identical
> formula
> > will change with every line.
> > Example:
> > Line 1000: tmp[100]=foo(tmp[101],tmp[102]);
> > Line 2000: tmp[200]=foo(tmp[201],tmp[203]); // dang it, not tmp[202] but
> > tmp[203]
> > It is like with penrose tiling. It seems all identical but the details
> > break it. You just do not find two identical local areas. No-where. And
> if,
> > you have to particularly search for them by brute-force, and that should
> > become useless whenever the particular pattern you try to find does just
> > not exist in that particular user's instance.
> >
>
> Surely this is screaming out for a table?
>
> const int foo_table[][3] = {
> { 100, 101, 102 },
> { 200, 201, 203 },
> ...
> };
>
>
> for (int i = 0; i < 100000000; i++) {
> tmp[foo_table[i][0]] =
> foo(tmp[foo_table[i][1]], tmp[foo_table[i][2]]);
> }
>
> This will turn your million-line program into a four line program with a
> big table, which will compile quickly and run faster.
>
>
>
>
