[PATCH] Move TargetLibraryInfo data from two files into one common .def file.

[Jan Voung]

Hmm, I don't have strong feelings either way, except that I think the enum and the string in the .def file should be clustered together so that it remains clear both are simultaneously defined whenever adding a TLI function.

I guess there is a spectrum of flexibility vs doing exactly what is needed for the current uses w/ strict error checking.

Most flexible: what I had before. Basically a for-each macro where the user can do whatever with the enum name and the string (e.g., could fill in a bunch of cases in a switch statement, not just define the enums / string table).

Middle: What I have now. Can't for-each on both the enum and the string simultaneously, but can for-each individually. This still has a bit of flexibility so that e.g., you can put the comma earlier or later

enum Func {

  InvalidEnum

#define TLI_HANDLE_ENUM(enum_variant) , enum_variant
#include "llvm/Analysis/TargetLibraryInfo.def"
}

vs

enum Func {
#define TLI_HANDLE_ENUM(enum_variant) enum_variant,
#include "llvm/Analysis/TargetLibraryInfo.def"

  NumLibraryFuncs

}

Strict:
#define TLI_HANDLE_ENUM
#include "llvm/Analysis/TargetLibraryInfo.def"

And then internally, "llvm/Analysis/TargetLibraryInfo.def" will check that only one of the TLI_HANDLE_* are defined at a time, and probably define some other local macros so that we still get the clustering of the enum and the string in the .def file.

As far as consistency w/ other .def files, from some sample of the existing .def files, they seem to follow the "Middle" option, though I guess many .def files are used for more complicated constructs.


http://reviews.llvm.org/D7845

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/