PGO: Statically generate data structures

[Duncan P. N. Exon Smith]

On Mar 17, 2014, at 1:21 PM, Justin Bogner <mail at justinbogner.com> wrote:

> "Duncan P. N. Exon Smith" <dexonsmith at apple.com> 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...