eric the fruitbat

The Good IR: Other Control Flow Structures

erich — Thu, 02 Feb 2012 02:39:58 +0000

In my last post on The Good IR, I had arrived at a representation with two invariants:

Only BasicBlock’s carry information about the ControlFlowGraph; No other edges are allowed between BasicBlocks.
All BasicBlocks end with a control transfer Instruction.

I focused that post solely on the if-then-else control flow structure. I would now like to demonstrate how those invariants translate to the while-loop and if-without-else. Although other languages have do-while, for-loop, and switch-case, I won’t be addressing those now. Instead I’m limiting my focus on a much simpler language (that used by CS241 here at UCI). I want to get a clear picture of how the if-else and while-loop work, before complicating the picture with Return. So, for this post, I’m assuming that we have ‘the usual case’ where the ‘stuff’ inside the body of a loop or branch of an if-then doesn’t proceeds ‘normally’ and doesn’t exit the function.

While Loop
while (cond) { // stuff }

We should not two important aspect of the illustration:

The body of the loop is fully general. That is, I wanted to make clear that the ‘stuff’ in the loop body might have control structures which cause a separation of the first block of the body from the last block. This separation is indicated by a series of small orange blocks.
Not in the illustration is a restriction on the instructions in the loop header. During a parse, when the loop is encountered we must create a new block to store two items: The instructions for evaluating the loop condition and the ConditionalBranch. We do not include instructions for any statement prior to the loop condition, even if such statement appear in the source program. We do this because, we wish to evaluate only the conditional and no other instructions, when control is restored on the loop’s backward control flow edge.

Given these observations. The presence of UnconditionalJump and ConditionalBranch is straightforward, and needs no modification from the last post.

Consider the degenerate case, when the loop body is empty. We could choose to draw the control flow graph omitting the body node. We decide not to do so, because it creates a special case. Instead we prefer that the loop body contains at least one block, even if that block holds only an UncoditionalJump back to the loop header block.

Forcing all loops to have at minimum 3 nodes: the loop-header, the body, and the exit block; gives us a stable footing for control flow optimizations which are implemented later in the compiler. It also gives us another invariant: No block points back to itself, all blocks always point to other blocks.

If-NoElse
if (cond) { // stuff }

The if-noelse is handled similarly. We do not have to create any instructions other than ConditionalBranch and UnconditionalJump. Again, we prefer to keep that ‘empty’ else branch. Regularizing the if-then-else to a minimum of 4 blocks: the if-header, then-block, else-block, and join-block. Always creating these blocks definitely helps the control flow graph keep an organized and uniform appearance, especially when you consider the nesting of several different control flow structures. An example from the last post would be quite unmanageable without the presence of these ‘empty’ blocks. In the if-then-else control structure, keeping these blocks aids in the placement of SSA φ-instructions, as well as control flow graph traversals.

Design Rule of Thumb: Don’t have the parser optimize away empty blocks, they’re actually useful to keep around (both for SSA and CFG traversals).

Transforming Heuristics

erich — Wed, 01 Feb 2012 21:51:53 +0000

Many of the real problems in the world are NP. Things like Scheduling, Register Allocation, Routing packages, etc. In solving these really hard problems, we invent heuristics. Typically such heuristics are specific to the problem domain. For example, UPS might exploit certain characteristic about the geographical layout of the country; they face a certain subset of all possible graphs, and can exploit those features.

But we know that the NP problems are all reducible to each other. So, don’t the heuristics transform as well?

That is, given a heuristic that works well for the Knapsack problem, how well does that same heuristic (transformed) work on the Travelling Salesman Problem?

Public School, it is a Prison

erich — Wed, 01 Feb 2012 10:32:21 +0000

How the Public Schools Keep Your Child a Prisoner of the State by Karen De Coster, has a few interesting links about how public schools act like prisons for both mind and body.

A really well researched article on equality via the school system:
“Compulsory schooling not only fails to achieve its egalitarian goal, but by subjecting all to the same studies in lockstep fashion effectively denies them any real opportunity at all.” [Equality" vs. "Equity, ed. William F. Rickenbacker, San Francisco: Open Court Publishing, Inc./Fox & Wilkes, 1998]

Milton Friedman points out that the tasks of funding and administration can (and should) be separated: The Role of Government in Education.

Don’t Fear the Mistakes

erich — Wed, 01 Feb 2012 05:13:00 +0000

During teaching, there is a fascinating (and unfortunately common) problem: Students are VERY reluctant to suggest an answer, for fear that they might be wrong.

Salman Kahn, noticed this phenomenon after he started doing videos for his niece and nephew: (I’m paraphrasing) “The last thing they needed was for me to be there expecting an answer.”

Teachers at the university level are fighting a behavioral lesson that we pick up in elementary school. Although young students often have the bravery (or lack of self-awareness) that allows them to speak up in class, it’s consistently beaten out of them: There’s nothing more degrading than being laughed at by the rest of the class. The other children are so insecure themselves, that they’ll take every opportunity to pick themselves up by mocking others.

Also, even for the talented students, if they are praised about their intelligence they will end up taking fewer risks: and try fervently to be wrong less. This lesson comes from Carol Dweck’s work: Praise for Intelligence Can Undermine Children’s Motivation and Performance. [Why do some people learn faster?]

Naturally, almost everyone will leave the early public education system less excited than when they entered. University and College teachers then have the problem of rekindling the excitement and interest we were all born with. But to accomplish this, we must find ways of fighting the earlier training: we must encourage participation and the mistakes that come with exploring.

John Holt has a book, “How Children Fail”, which contains the following conclusions:

Schools promote an atmosphere of fear.
Boredom serves as another major obstacle.
‘Cookie-cutter’ education does not cultivate intrinsic interests and learning.
Mixed Signals: Parents praise curiosity and questions, school does not.
There is no single body of information that all children should learn.

So, what can be done?

Exercise Choice Theory. Recognize that you can cultivate a positive attitude, and change your response.
Fail more often, and get used to how it feels. Routinely try to go beyond your comfort zone.
Push yourself. Don’t stop at the first obstacle. Try a different approach. Don’t avoid things you dislike.
Debrief your experience. If you don’t succeed, spend time to figure out why not. Brainstorm, and loop back with any new approaches.
Also, Aligna Tugend’s book “Better By Mistake: The Unexpected Benefits of Being Wrong” contains still more lessons.

That works for oneself, but what about the students?

If they are afraid of giving the ‘wrong’ answer to a question, change the question to “tell me something that doesn’t work.”

A New Field: Information Type Flow

erich — Mon, 30 Jan 2012 18:35:17 +0000

In my last post on Information Flow, I noticed that some flows are more informative than others. I used a switch statement for my illustrative example of that observation. But, from my experience as a software developer, I have a small aversion to switch statements. Usually, when I feel compelled to use one, it’s because I’m not using OO design principles. It’s because that switch should really be replaced with a polymorphic dispatch.

So, thanks to my Super Awesome Postdoc, we coined a new field as a result. It stands to reason that Information Flow analysis can be performed on types, just as it has previously been performed on values. A collection of questions suggest themselves:

Is it useful? Does sensitive/interesting/important information actually leak as a result of polymorphism? For a typical program, how much does the polymorphic dispatch reveal about your system? On the one hand, I think not so much; because the dispatch is taken on type-compatible instances. On the other, perhaps alot, if you represent much of the problem’s domain in the type system (AuthenticatedCustomer vs Guest). How do standard practices such as Design Patterns affect a programs information type flow?
What does the analysis entail? Does it require a statically typed language, so that you can easily identify the polymorphic call sites? Do you still have to provide instrumentation that take place at runtime?
What about dynamic languages? Does type-information make its way into dynamic programs? Even in a dynamic language, are the programmers developing as if they had a strongly typed world?

Gold is Money

erich — Mon, 30 Jan 2012 01:34:35 +0000

I would like to evaluate whether or not Gold functions better than paper as a currency. This subject comes up, because of an engaging argument that I had last night about the U.S. Constitution and it’s purview of the monetary policy of the U.S. government. In particular, though the Constitution does not define what Money is when it allows the Federal Government the power to “coin money” [Article 1, Section 8], it also expressly denies the States from “mak[ing] any Thing but gold and silver Coin a Tender in Payment of Debts”[Article 1, Section 10]. Why the explicit mention of precious metals? Wouldn’t a paper currency (such as any of those used throughout U.S. history) be just as good, maybe better?

Even though Gold and Silver have a long history of being used for currency, I’ve thought often that the exercise of digging gold out of the ground, purifying it, stamping it with an insignia, and then locking it away in a vault as you trade a representational paper certificate instead, was a rather silly thing to do. (Only about 40% is actually used this way. 50% goes to jewerly and 10% to industry [wikipedia]) Why should we use this stuff as money? Can’t you dispense with the gold, and just use the paper instead?

That great historical thinker Aristotle identifies the utilities essential to a currency:

Durable: Money must stand the test of time and the elements. It must not fade, corrode, or change through time;
Portable: Good money needs to hold a high amount of ‘worth’ relative to its weight and size;
Divisible: Money should be relatively easy to separate and re-combine without affecting its fundamental characteristics. An extension of this idea is that the item should be “fungible”, defined as “being freely exchangeable or replaceable, in whole or in part, for another of like nature or kind.”
Intrinsically Valuable: This value of money should be independent of any other object and contained in the money itself, starting with rarity.

Clearly, gold by its very nature is durable, portable (though not so much as paper), and divisible. But some contend the last part: it doesn’t have a clear intrinsic value other than rarity.

But platinum (and many other metals) are more rare than gold, why not use one of them? Still other metals are more difficult to recover from raw earth, making them more valuable as measured by the economic cost of obtaining them, why not use one of them?

Both of these objections can be dismissed on the basis of recognizablility: Other metals are all silvery in color, while gold stands apart for its yellowish color. This property makes it alone easily distinguishable from a counterfeit. So the ‘intrinsic value’ of gold is actually derived from three aspects: rarity, difficulty to produce, and recognizablility. These aspects plus the other utilities make gold the best suited natural material for money. We should therefore add to the ‘intrinsic value’ a fourth aspect: natural suitability as money.

But a printer can produce paper currency with fancy designs, for recognizability, and in limited quantities, for artificial rarity. Thus simulating those aspects which make gold so suitable as a currency. Also, in practice, people do not usually cut the coins in half to make change for a transaction because it trespasses upon the ‘borrowed trust’ of the mint, defacing the stamped insignia and destroying future transaction value. So, divisibility isn’t nearly as strong as the other utilities. Paper currency can be made better than gold in rarity and portablity so it should function better as currency.

Yes, except for that rarity and recognizability do not automatically satisfy intrinsic value. Gold is also difficult to produce. And no matter how complex the anti-counterfeit designs raise the cost of printing, a real government would never try to make the cost of printing a bill equal to the cost of extracting the equivalent amount of gold, because paper lacks durability. Paper bills must be replaced as they wear out.

So, knowing this, how can a government give a paper currency an intrinsic value that the populace will respect? Declare the paper currency good for the payment of taxes. Now, some initially worthless paper, printed in limited amounts and stamped with recognizable designs becomes useful for maintaining ones lifestyle outside of a jail cell. Now people desire having at least some amount of the paper, and are therefore willing to trade to get it. So, by Gresham’s Law paper rapidly becomes the only currency in circulation.

Further, the government now has more control over the currency supply, and has the power to practice monetary policies which can stabilize prices. It is easier for the government to print money as the economy expands than it is to extract more gold. But, it should be noted, that governments historically have not exercised this beneficial aspect of control. Rather, they routinely opt for inflationary measures which destabilize prices. Given that I harbor a strong distrust of government, I actually see this power as a drawback rather than a benefit. You see because gold is a limited chemical element, it can’t be replicated at will: So the use of gold as money prevents government from counterfeiting! Gold is more durable than any government and its printing press.

There is one standing objection I have not yet addressed: shouldn’t the money supply expand with the economy? Adopting a rare and finite substance such as gold prevents that flexibility.

I was not able to verify this on my own (even looking in google scholar), but I’ve heard Doug Casey say that the price of a tunic, sandals, and belt in ancient Rome could be purchased for about 1 troy oz gold; roughly equivalent to a fine suit, shoes, and belt today (at $2,000/oz gold). Though it wouldn’t have been possible to obtain such high quality fabrics then, the price for items functionally equivalent has remained comparable across 2,000 years of economic growth.

Furthermore, it should be noted that as the economy expands, so too does the technology for extracting minerals. Thus we can add to the gold/money supply as the economy grows (though maybe not at exactly the same pace). And, since the economy is now so vast and most of the gold has already been recovered we should not experience any large swings in the money supply (such as Spain experienced during the plunder of South America). Even if gold is a deflationary currency (because only a finite amount exists and extraction is asymptotically approaching zero while economic growth remains exponential) the very predictability of its supply is useful as a stable bedrock for pricing, and the inability of government to counterfeit gold prevents undue market interference for political purposes.

Because paper must make up for intrinsic drawbacks via government coercion, I conclude that Gold is natural Money.

The Good IR

erich — Fri, 27 Jan 2012 09:13:19 +0000

After parsing, each function can be represented as a ControlFlowGraph of BasicBlocks. Each BasicBlock holds a list of Instructions. For illustrative purposes Instructions are colored Blue and BasicBlocks are colored Orange.

I’d now like to address the question: What should the ConditionalBranch instruction at the end of the If-Header point to?

Option	Illustration	Pro	Con
Point at the following BasicBlock		Convenient: the target BasicBlock is available during parse.	Redundant: the If-Header block has a ControlFlowGraph edge with the same destination. Non-Uniform: it’s unsettling to have some instructions (such as Add/Sub/Mul/Div) point at other Instructions, but then deal with ConditionalBranch as a special case.
Point at the first Instruction of the following BasicBlock.		Uniform: Instructions point only to other Instructions.	Redundant: The If-Header block has a ControlFlowGraph edge with the same destination. Problematic: Can you guarantee that target all blocks have at least one instruction to point at?

The common drawback with both of these proposals, is that of Redundancy. At some point, during a future optimization pass, we might like to transform the ControlFlowGraph. If such a transformation requires that we update both the BasicBlock→BasicBlock edges and the target of ConditionalBranch Instructions, then we are more likely to have a bug. We must put forth extra effort in keeping both kinds of link synchronized.

We can avoid this common drawback by adding a layer of indirection/abstraction. Instead of forcing the ConditionalBranch instruction to maintain a pointer to its target, we can access the target through a function. That function can query its own BasicBlock about the outgoing ControlFlowGraph edges, and return either the target BasicBlock or the target BasicBlock’s first Instruction. By making this abstraction, not only do we avoid the extra effort of keeping redundant links synchronized, but we also promote uniformity in the design through the introduction of a new invariant: Only BasicBlock’s carry information about the ControlFlowGraph; No other edges are allowed between BasicBlocks.

Illustration	Option	Pro	Con
ConditionalBranch queries its BasicBlock.		Uniform: The only links across/between BasicBlocks are control flow edges held by BasicBlocks. Convenient: Do not have to synchronize redundant information.	Performance: A function call is required when asking a ConditionalBranch for its targets.

Now that we have decided that ConditionalBranch will return information about the targets via a function call, we visit the question: Is the branch target the successor BasicBlock or is it the successor BasicBlock’s first Instruction?

To answer this question, I’m going to assume that the Internal Representation can also be interpreted. Such a design has the advantage that we can verify the structure of the IR by interpreting it after construction and between transformation/optimization passes.

Let’s assume a simple interpreter of the form:

Instruction i = function.firstInstruction()
while (!i.isEnd()) {
    i = i.evaluate();
}

This interpreter exploits polymorphic dispatch on the Instruction hierarchy. We can express the loop concisely because we follow the invariant: evaluate always returns the next instruction to be executed. This is analogous to setting the program counter (pc), but avoids passing the pc as either a function parameter (which most evaluate implementations will ignore) or as a global variable (yuck!). Importantly, this loop has no concept of BasicBlock’s; it evaluates only Instructions.

So, in the interests of keeping the interpreter loop immaculately clean, we have only one choice: ConditionalBranch must return the first Instruction of the target BasicBlock. But, this answer contains a potential pitfall: Can we guarantee that all target BasicBlocks have at least one Instruction?

Consider the following example code, and associated ControlFlowGraph.

Code	ControlFlowGraph
if (cond1) { // do something 1 } else { if (cond2) { // do something 2 } }

Notice that, those blocks which do not have instructions in them have been left blank. Suppose that cond1 is false and cond2 is false so that the interpreter ends up following the chain of empty BasicBlocks. We notice that there is immediately some difficulty in having the interpreter transfer from ConditionalBranch(cond2) to the the first instruction of the (empty) target BasicBlock. One possible solution comes to mind: Have ConditionalBranch(cond2) attempt to iterate the following blocks until it finds one with a first Instruction. Although this will work, it feels rather kludgy, and we should continue our search for a clean design.

Let’s analyze the situation in more detail. Specifically, let’s look at the last instruction of the ThenBlock. It contains code for do something 1, which has been left unspecified to emphasize the fact that it can be completely arbitrary. However, (because we are gifted with knowledge of assembly) we have advanced some foresight: when the instructions are finally emitted from the CodeGenerator in a linear stream, we must insert an UnconditionalJump which bypasses the code for the ElseBranch (assuming one exists), and lands the program counter at the first Instruction of the JoinBlock.

In our IR interpreter, the last Instruction of the code inside the ThenBlock can be arbitrary, so it will have some difficultly detecting that control should be transferred to the following JoinBlock. We can alleviate this difficulty by analogy to our foresight, and introduce an UnconditionalJump in the last BasicBlock of the ThenBranch. As with the ConditionalBranch, the UnconditionalJump will rely on the ControlFlowGraph edge (we are guaranteed only 1) of its BasicBlock to determine the following instruction during interpretation.

We now have two situations of BasicBlocks which end in a kind of control transfer Instruction:

If-Headers and Loop-Headers, which end in a ConditionalBranch Instruction.
The Last BasicBlock of a ThenBranch, which ends in an UnconditionalJump.

The explicit control transfer in these situations allows the interpreter to easily determine the next instruction, even though it lies in a different BasicBlock. That is, in these two cases, the interpreter does not need to know about the existence of BasicBlocks. Due to this advantage, we should try to arrange one of these two situations to our current concern: the empty BasicBlocks in the ElseBranch.

Only one of the two previous instructions applies: the UnconditionalJump. It certainly doesn’t hurt the semantics of the ControlFlowGraph to insert an UnconditionalJump at every edge (even fallthrough edges). So we can safely coin the invariant: All BasicBlocks end with a control transfer Instruction (ConditionalBranch or UnconditionalJump). This invariant unifies our design, and allows the interpreter to iterate only over Instructions.

Additionally, we now also have at least one Instruction (the UnconditionalJump) in every BasicBlock! So, we can positively guarantee that a ConditionalBranch is able to return the first Instruction of its target BasicBlock. Indeed, all control transfer Instructions are able to do likewise.

Deliberate Practice: Learn to Type

erich — Tue, 24 Jan 2012 09:00:51 +0000

If you’re gonna be in the software industry. You have to communicate, not only through code but also through email, forums, IRC or IM. It’s not so important that you be a fast typing in order to bang out code really fast. Rather, you should be a fast typing so that it doesn’t hold you back. So that you don’t have to sacrifice anything. So that you can participate in the electronically held discussions. So that you can be digitally present.

Don’t let the lack of little things like typing skills hold you back from practicing the larger things.

see:
1. Steve Yegge
2. Sacha Chua

Now, go forth and practice!

–
UPDATE: Actually, I found an even better alternative: Plover which essentially turns your existing keyboard into a steno machine (provided that it supports chording). The author has a fantastic series of articles, including one about how steno can drastically improve your coding. Perhaps, I shouldn’t worry too much that I’ll never find a keyboard with the my ideal layout.

Project Course in Web Services

erich — Tue, 24 Jan 2012 04:10:29 +0000

I’ve just finished reading Phillip Greenspun’s experience report, Teaching Software Engineering, which details a project course in building Web Services. Even though I personally, hate the Web’s architecture (but that’s a rant for some other time), it still remains as THE most influentential and convenient place to showcase one’s work. It’s also convenient for shopping, learning, participating in niche communities, etc. The Web has real business value, and is therefore un-ignorable.

Based on his experience with the course, Greenspun had some nice quotes, which pertain to thought’s I’ve been building recently as I’ve been digging into the question: ‘What makes education valuable?’.

Building Real-World Skill

We’d like our students to be able to take vague and ambitious specifications and turn them into a system design that can be built and launched within a few months, with the most important-to-users and easy-to-develop features built first and the difficult bells and whistles deferred to a second version. We’d like our students to know how to test prototypes with end-users and refine their application design once or twice within even a three-month project.

For every project in 6.916 Classic, we insisted on having a client. This is a person who can describe desired capabilities for an information system but offers no hint as to how to build it. The best clients are people who are in fact passionate about some sort of Internet service and completely clueless about all matters technical. Good sources of clients are dotcom CEOs, MBA students, non-profit organization directors, and university administrators.

we invited alumni who were working as professional software engineers to return to campus on Tuesdays and Thursday evenings to coach students during the 6 hours of supervised laboratory time per week. There are perhaps 10 alumni out there for every current MIT undergraduate.

The best projects were ones with clients who had the wherewithal to extend and maintain the service after the course is over, possibly by hiring the students who built it.

A plethora of useful circumstances are brought into alignment: Students are challenged in the same underspecified way that they’d face in a real job. That challenge is met by performing fast, iterative development, ala XP or Agile. They get to interact with an actual customer: deriving project worth from satisifing the client, and building experience with client rejection and other realistic bumps. Finally, they get to forge connections in a business network, which can help them when entering the job market.

Student Learning

Software engineering is a craft and can only be learned by practice.

Our experience [with producing five complete internet service projects] contrasts with typical software engineering courses in which a student builds only one application (or a piece of one application) during the entire semester. Research on simple word association tasks has demonstrated that people who learned to perform quickly but not accurately would have remarkably good recall even months later and, with a bit of practice, could always be made to perform accurately. Whereas people who were slow but accurate forgot all of their skills within a month or two.

Just another example where Quantity trumps Quality. People learn by actually practicing and experimenting. They do not learn by listening to lectures. Learning can be reinforced by discussion and analysis, by questioning and tweaking.

Building a Portfolio

At the end of the semester, a student in 6.916 could look back upon four or five completed Internet services. The first ones that he or she built had been done for the problem sets. They won’t have been complex. They may not have been built to a very high standard of polish. But their existence enabled nearly all students to become fluent in the arts of designing a data model, specifying a page flow, and implementing the designed system in SQL and a procedural language.

At the end of the semester we drill into the students’ heads the cold hard facts of the world: nobody owes them attention. We have each student group prepare an overview page that is a single HTML document, with a few screen shots, that demonstrates the major functions of the Internet service that they’ve built. Visit http://philip.greenspun.com/seia/gallery/ to see these pages.

Finally, it has been fun to watch our students graduate and go onto the job market. During job interviews they are able to point their interviewer to the URL of the running Web service that they developed during 6.916. Oftentimes, the student-built service is more sophisticated and is running on a more reliable infrastructure than most of the Internet applications launched on the public Internet by the interviewer’s company!

This is where I’ll have to distinguish my school: The lessons are online, but the workshop let’s you build your Programmer’s Portfolio.

Reaching for the Sky

Universities have long taught theoretical methods for dealing with concurrency and transactions. The Internet raises new challenges in these areas. A dozen users may simultaneously ask for the same airline seat. Twenty responses to a discussion forum question may come in simultaneously. The radio or hardwired connection to a user may be interrupted halfway through an attempt to register at a site.

In the second problem set (“reservation system”), students built a collaborative conference room scheduling system. This raises the problem of concurrency in a natural manner. Every student can understand that you don’t want to book two people into a room at overlapping times.

Third, because all of the projects have a predictable shape we’ll be able to introduce distributed computing challenges merely by having students offer services to each other.

Students said that the “metadata” problem set was very valuable for speeding work on their projects. Students were asked to build a knowledge management system by writing a computer program to write all of the computer programs. I.e., we gave them a machine-readable language for representing the system capabilities and user experience and asked them to write a program to generate the SQL data model and then the scripts to support the user experience.

In the final exercise of the problem set, we ask the students to mark certain rooms as requiring fees. Users who wish to book those rooms must supply a credit card number. At MIT we hook up the servers to a live merchant account at CyberCash. Thus our better students will be able to open their credit card statements in the middle of the semester and discover a few dollars in charges made by their own Web server.

UPDATE: Greenspun also has a quick bullet list of all the lessons learned, and outline of the course’s structure.

Not All Flows are Considered Equal

erich — Mon, 23 Jan 2012 19:56:24 +0000

When I was writing last post about information flow terminology, I noticed something interesting: when knowledge of control flows are used to determine the values of variables, some branches yield more information than others. Previously, I had only considered the binary if-then-else branch. Today, I shall examine a switch-case statement, which exhibits asymmetric information flow.

/* pick s from 1 to 3, inclusive */
switch(s) {
case 1: k = 1; break;
case 2: k = 2; break;
case 3: k = 2; break;
}

After this code segment has executed: k is one of two values: 1 or 2. However, one of these values is more informative for the observer. If an observer sees k == 1 then she can infer that s == 1. On the other hand, if the observer sees k == 2 then she can only infer s != 1 (or s in {2,3} with knowledge of s‘s distribution).

For control structures this simple, a static analysis could be run on the code, and provide a result graph of how influential each variable is on others. This graph could be used to quantify how much information might be leaked to an observer. Unfortunately, it comes with the limitation that each branch is considered as drawn from a uniform distribution, which may not be true of actual runtime values.

Nevertheless, I think the ability to statically quantify how much information can be leaked via control flow branches, might be useful for:

deciding which variables need tracking,
where instrumentation/wrappers/labels might be omitted,
where inspections/checks must be inserted,
finding variables which fall below a certain leak threshold.

I would really like such an analysis to tell me, for example, whether a variable holding a password is potentially leaked, and if so, how many bits. Or, to list me all the variables of my program in order of how much they might leak.

The inference here sounds like the same as in Probabilistic Predicative Programming by Eric C.R. Hehner (whom I met when Wayne Hayes invited him to give a Friday Seminar talk in Dec 2010), except that it runs backwards on the control flow.