Following up on my introduction of the StringRef type, I wanted to
clean up the API for getting and setting the name of an llvm::Value.
There are a number of problems with the current API:
1. There are too many ...Name methods.
2. getName() returns an std::string, which is expensive.
3. getName() is frequently used to derive new names, which are passed
to setName(). Currently this uses std::string concatenation.
4. In a Release-Asserts build, we usually don't name values, but we
still end up with the overhead of creating and destroying strings we
either don't use, or don't care about.
Problem #1 can be addressed solely with the StringRef type, but it
requires either updating many clients (which frequently do something
like (getName() + ".not")), or making StringRef transparently convert
to an std::string, which hides inefficient code.
Chris and I discussed this problem and came up with what I think is a
nice and tidy solution, based on introducing a new type for handling
the results of string concatenation. I tried to do an extensive
evaluation of the results to make sure the approach was working &
worth it, and in true salesman style, I'm going to give you the
benefits first before the implementation! 
On 64-bit Darwin, using gcc-4.2 to compile LLVM; and using
instcombine.bc (the .bc for InstructionCombining.bc) as a test case:
Code size:
-1% on opt (from 5315144 to 5249024)
Memory allocation:
-10% calls to malloc (from 944090 to 832970), for 'opt -f -o /dev/null
-std-compile-opts instcombine.bc'
Performance:
-1% for the preceeding opt command.
Compile Time:
Compile time for InstructionCombining.cpp got slightly faster,
although gcc's memory usage increased by ~15%.