Change control flow generation scheme

[mskvortsov]

[azhogin]

I had an idea to represent function adresses as continuations. And add continuation type to language like slice/builder/cell/tuple. Would it be easier/harder to support function addresses as continuations with this path accepted?

[mskvortsov]

The idea is surely eligible for the kind of machine you have. Though I'm not sure that LLVM is a right framework for trying to implement the idea.

To answer your question: it would be slightly harder, I guess. But does it matter? What is the example of a function address usage in a code of a contract...

[mskvortsov]

What actually bothers me about this approach is a support of high-level control-flow primitives like WHILE, UNTIL, REPEAT...

[akiramenai]

@mskvortsov you've mentioned that the approach you use in the PR doesn't work well with huge functions (with more than 255 BBs). Do you plan to modify the solution somehow (e.g. use tuples of continuations) or do you want to abandon the idea?

[mskvortsov]

From what I see from performance analysis of a certain C++ sample, a huge number of basic blocks (301 in that code to be precise) looks like a problem by itself. Here is an execution statistics of logically the same submitTransaction method coded in C (15k of gas) compared to C++ (24k of gas). C:

('comparison', 394, '2.62', '%')
('const_literal', 1632, '10.9', '%')
('dictionary', 1391, '9.25', '%')
('application', 1826, '12.1', '%')
('cell', 4237, '28.2', '%')
('codepage_primitives', 52, '0.346', '%')
('control_flow', 470, '3.13', '%')
('tuples', 98, '0.652', '%')
('exceptions', 222, '1.48', '%')
('debug', 0, '0', '%')
('implicit', 1035, '6.88', '%')
('arithmetic', 152, '1.01', '%')
('stack_mapulation', 3524, '23.4', '%')
('total ', 15033)

C++:

('comparison', 696, '2.91', '%')
('const_literal', 3531, '14.8', '%')
('dictionary', 1266, '5.3', '%')
('application', 1972, '8.25', '%')
('cell', 4729, '19.8', '%')
('codepage_primitives', 52, '0.218', '%')
('control_flow', 712, '2.98', '%')
('tuples', 362, '1.51', '%')
('exceptions', 318, '1.33', '%')
('debug', 0, '0', '%')
('implicit', 2530, '10.6', '%')
('arithmetic', 206, '0.862', '%')
('stack_mapulation', 7530, '31.5', '%')
('total ', 23904)

Stack manipulation primitives, implicit jmprefs and rets, and literals add roughly 7.5k of gas. My current guess it's because of stack modelling goes nuts on this huge number of BBs.