PGO: Statically generate data structures

[Duncan P. N. Exon Smith]

On Mar 17, 2014, at 2:31 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Mon, Mar 17, 2014 at 2:27 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> >> +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...
> 
> Why is this a better name?
> 
> In particular, I much prefer __llvm_... or __clang_... as the prefix to ensure we're not stomping on other implementations' names...

Apparently the struct and typedef names aren’t relevant in C.  They don’t make
it past the translation unit (i.e., PGOProfile.c), except via debug info, and
even then the name is tagged with the file it came from.

The only time there’s an ambiguity is if a user happens to have their own type
called ProfileData and tries to cast something to ProfileData* in the debugger.
The debugger will have to pick one of them.  However, even that only comes up
if compiler-rt was built with debug info, which is a strange idea.

Nevertheless, this wasn’t obvious to me (or you), so I’ve changed both names
to __llvm_pgo_data in r204083.  Now it's obvious that it works.