|Interpreters and caller-saved registers firstname.lastname@example.org (2023-10-13)|
|Re: Interpreters and caller-saved registers email@example.com (Thomas Koenig) (2023-10-15)|
|Re: Interpreters and caller-saved registers firstname.lastname@example.org (2023-10-19)|
|Re: Interpreters and caller-saved registers email@example.com (Thomas Koenig) (2023-10-22)|
|Re: Interpreters and caller-saved registers firstname.lastname@example.org (2023-10-24)|
|Re: bug fixes, Interpreters and caller-saved registers email@example.com (Kaz Kylheku) (2023-10-25)|
|Date:||Thu, 19 Oct 2023 17:14:28 +0000|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="87340"; mail-complaints-to="firstname.lastname@example.org"|
|Posted-Date:||19 Oct 2023 14:51:59 EDT|
Thomas Koenig <email@example.com> writes:
>It is well known that compilers in general and gcc specfically often
>generate superflous register moves
>However, if this got worse between releases, this is a regression.
>Those get higher priority for fixing. So, if it is reasonable
>to generate a reduced test case (for which cvise, for example,
>is an excellent tool) so filing a bug report would be a good thing.
If you want to file such a bug report, I can give you the commit of
Gforth before we added all the workarounds, where all the problems
are visible without ado.
>This sort of code is an example of the contradictions in today's
>compiler technology. On the one hand, they do amazing optimizations
>on large amounts of code which no programmer could hope to reach
>while staying productive.
There are certainly cases where compilers loop-unroll (plus
ramp-up/down and compensation code) code into huge swaths of code that
makes it hard to see where the action is going on, but amazing?
>So far, nobody has found an algorithm for "just remove the
>silliness" from compiled programs. Maybe it would be feasible to
>run some peephole optimization as last passes which could improve
>code like the one above, but that might also be difficult in the
>more general case where registers are reused in other basic blocks
>(which would mean just to redo the register allocation).
Yes, I doubt that it can be solved with peephole optimization, or it
would have been done already.
M. Anton Ertl
Return to the
Search the comp.compilers archives again.