Re: Possible data allocation and instruction scheduling algo...

Ray Dillinger <bear@sonic.net>
6 Feb 2002 23:46:09 -0500

          From comp.compilers

Related articles
Possible data allocation and instruction scheduling algo... ollanes@prodigy.net (Orlando Llanes) (2002-01-24)
Re: Possible data allocation and instruction scheduling algo... bryan.hayes@hayestechnologies.com (2002-01-30)
Re: Possible data allocation and instruction scheduling algo... bear@sonic.net (Ray Dillinger) (2002-02-06)
Re: Possible data allocation and instruction scheduling algo... ollanes@pobox.com (2002-02-16)
Re: Possible data allocation and instruction scheduling algo... ollanes@pobox.com (2002-02-16)
| List of all articles for this month |

From: Ray Dillinger <bear@sonic.net>
Newsgroups: comp.compilers
Date: 6 Feb 2002 23:46:09 -0500
Organization: Compilers Central
References: 02-01-118 02-01-161
Keywords: code, optimize
Posted-Date: 06 Feb 2002 23:46:09 EST

Bryan Hayes wrote:
>
> If you more realistically define it as the compiler doing something
> similar to a good programmer or achieving similar results then the
> answer is that good compilers already do optimize the "assembly
> output" (instruction selection + scheduling etc.) to a significant
> extent.
> Anyhow, no compiler matches an experienced human assembly programmer
> (or even comes close, at least in most cases).


I dunno. There are many systems out there now that accept "the 80386
instruction set" but which work best under completely different
optimization strategies and have different additional instructions,
extensions, numeric coprocessors, onboard caches, and MMUs etc, and a
significant fraction of them will mis-identify themselves in a
misguided attempt at backward compatibility.


It's getting seriously hard for a compiler to really know what the
hell its target is on the local machine, and even if you know what the
target is, sometimes the tradeoffs are hard to predict when deciding
how to optimize something. Lately I've been toying with the idea of
creating a "testing" extension which would run a bunch of
differently-optimized code segments and profile them to find out what
the heck the compiler really needed to deal with and pass the info
along in a config file.


Bear


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.