Comments on: Squeezing a CS Research Idea

By: moo

moo — Wed, 08 Jun 2011 00:00:39 +0000

By the way, I have the opposite opinion from Ben about manually-specified aliasing. Its too costly and in many cases undecidable for the compiler to find the right places where “restrict” can be used. As the programmer, I want the ability to declare to the compiler “I promise this thing does not alias with anything else”. I also want other types of programmer-annotation, such as “force-inline the called function at this specific call-site” and “assume this expression is true, and make whatever use of that you can to optimize”. Compilers cannot know all of the context that the programmer knows about how this code will be used. For example, maybe you have a code generator that generates thousands of similar methods and minimizing their code size (through controlling which things get inlined and which things don’t) is much more important to you than getting maximum speed out of them. As a game developer, I want a smart compiler that will make the right choice most of the time, but sometimes I definitely need to override its code-generation choices–game consoles have a fixed amount of RAM. (Its true that restrict has little effect on code size. I’ve seen cases where __assume can affect code size though, e.g. to eliminate NULL-checks generated by placement new)

By: moo

moo — Tue, 07 Jun 2011 23:46:06 +0000

There’s another flaw in this kind of analysis. When programmers use restrict themselves, they tend to only place it in the small number of “important” places for their program (e.g. low-level function where a lot of time is spent, and disassembly shows that the compiler generates the wrong code without the restrict). In this way, they extract a lot of the potential value of manually-placed restrict even though they only place it in a few extra places. What I think this research really shows is that “putting restrict everywhere it could possibly be put, gains almost nothing over manually putting it in a SMALL number of sensible places”.

The rule for programmers should be “don’t use restrict unless you KNOW you need it, and be extremely careful when you do use it”.

By: Ben L. Titzer

Ben L. Titzer — Thu, 02 Jun 2011 20:28:11 +0000

The article was about a much wider point but my feeling on the aliasing issue is that annotations are a big step backwards in terms of progress. It puts the complexity in the wrong place, and (at least in the case of the C annotations) opens another wormhole through which compiler optimizations mysteriously influence the behavior of programs.

My opinion as a compiler writer is that a compiler that is sufficiently advanced to be perform the kinds of code motion made possible by alias analysis should be capable of actually doing the analysis.

By: Owen

Owen — Wed, 01 Jun 2011 22:11:51 +0000

I’m not familiar with any code bases that use restrict heavily. It’s sort of a chicken-egg problem.

Compilers (except maybe MSVC) don’t implement aggressive alias analysis because it’s slow, and the efficient forms are patent encumbered. Because of this, very few aliases of this can be disambiguated. Thus it’s not worthwhile trying to implement aggressive restructuring optimizations that depend on aggressive AA. And then, since the compiler’s not going to do much them anyways, nobody actually bothers to write restrict qualifiers.

By: “Squeezing a CS Research Idea” | michael-mccracken.net

“Squeezing a CS Research Idea” | michael-mccracken.net — Fri, 27 May 2011 15:04:09 +0000

[...] Embedded in Academia : Squeezing a CS Research Idea. [...]