aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineFunction.cpp
diff options
context:
space:
mode:
authorSean Silva <chisophugis@gmail.com>2014-08-15 23:18:33 +0000
committerSean Silva <chisophugis@gmail.com>2014-08-15 23:18:33 +0000
commit42ec6fdf58f4226467aaecd07e2c7bfa0d667186 (patch)
tree3121b33f6a4b3a7be72bcf1f10ed08ea4b683920 /llvm/lib/CodeGen/MachineFunction.cpp
parente8bf7496531a08f3fc8dbef64dc4c5245f788d65 (diff)
downloadllvm-42ec6fdf58f4226467aaecd07e2c7bfa0d667186.zip
llvm-42ec6fdf58f4226467aaecd07e2c7bfa0d667186.tar.gz
llvm-42ec6fdf58f4226467aaecd07e2c7bfa0d667186.tar.bz2
[Support] Promote cl::StringSaver to a separate utility
This class is generally useful. In breaking it out, the primary change is that it has been made non-virtual. It seems like being abstract led to there being 3 different (2 in llvm + 1 in clang) concrete implementations which disagreed about the ownership of the saved strings (see the manual call to free() in the unittest StrDupSaver; yes this is different from the CommandLine.cpp StrDupSaver which owns the stored strings; which is different from Clang's StringSetSaver which just holds a reference to a std::set<std::string> which owns the strings). I've identified 2 other places in the codebase that are open-coding this pattern: memcpy(Alloc.Allocate<char>(strlen(S)+1), S, strlen(S)+1) I'll be switching them over. They are * llvm::sys::Process::GetArgumentVector * The StringAllocator member of YAMLIO's Input class This also will allow simplifying Clang's driver.cpp quite a bit. Let me know if there are any other places that could benefit from StringSaver. I'm also thinking of adding a saveStringRef member for getting a stable StringRef. llvm-svn: 215784
Diffstat (limited to 'llvm/lib/CodeGen/MachineFunction.cpp')
0 files changed, 0 insertions, 0 deletions