<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">Am Mi., 19. Dez. 2018, 09:03 hat denisgolovan <<a href="mailto:denisgolovan@yandex.ru">denisgolovan@yandex.ru</a>> geschrieben:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My personal wish-list is:<br>
- support for array calculations / automatic loop parallelization via SSE, AVX, etc.<br>
  Both static and dynamic arrays should supported. <br>
  Once implemented vector operations on arrays (ala APL) might be done using operator overloads.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There is already some vector operation optimizations (though right now I don't know the specifics when they're triggered) and there were some plans to improve on that. So, yes, this one is welcome. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Custom/separate allocators for dynamic arrays (to avoid manually patching compiler). <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Why do you need that? </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Coroutines. Portable library or in-compiler support.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">A library as first step would be more useful. Later on one can think about integrating it into the language itself. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Interprocedural optimizations (something akin to LTO)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">We already have WPO which does some things, so that can be build upon. Though it's always a two step approach. </div><div dir="auto">Implementing interprocedural optimizations on the node level might be interesting, though for now inline helps there... </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- inline assembler function support<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The main problem here is to model what registers an instruction uses and modifies so that the register allocator of the surrounding function can take that into account accordingly... Maybe as a first step we could allow in lining for funcrions that have a register clause with the touched registers... </div><div dir="auto">But yes, in the long term this would definitely be nice. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- proper macro language perhaps<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto">No. We already rejected such an idea some months ago.</div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div></div>