On Mar 17, 2014, at 1:21 PM, Justin Bogner <[email protected]> wrote:
> "Duncan P. N. Exon Smith" <[email protected]> writes: >> I’ve attached updated patches that address your comments. > > Thanks. This looks good to commit with one or two more little cleanups. Committed in r204079 and r204080. >> @@ -77,7 +79,11 @@ public: >> >> /// Get the string used to identify this function in the profile data. >> /// For functions with local linkage, this includes the main file name. >> - const StringRef getFuncName() const { return StringRef(*FuncName); } >> + StringRef getFuncName() const { return StringRef(*PrefixedFuncName); } >> + std::string getFuncVarName(StringRef VarName) const { >> + return Twine("__llvm_pgo_").concat(VarName).concat("_") >> + .concat(RawFuncName).str(); >> + } > > Using operator+ might be clearer for this. Way better, thanks. >> +typedef struct __llvm_pgo_data { >> + const uint32_t NameSize; >> + const uint32_t NumCounters; >> + const char *const Name; >> + const uint64_t *const Counters; >> +} DataType; > > It's odd that the name of this struct is nothing like the typedef. Also, > DataType is a pretty bad name. "struct ProfileData" is a pretty good > name, which you could then typedef to ProfileData if you like. Changed both names to __ProfileData. Still using __ to guarantee nothing clashes with user code. Given that this is C and we’re unlikely to compile compiler-rt with debug info, it may be unnecessary, but... _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
