[cfe-dev] Anemic support for processor based preprocessor defines

[Chandler Carruth]

Clang's processor-based defines are really bad currently. They are
hard-coded to 'nocona' without regard to the actual '-march' flag (much less
the -mtune flag). I would like to fix this.

I have hacked in support which matches the defines produced by GCC for the
various -march flags, however its extremely gross. The entire TargetInfo
interface in clangBasic is really crufty. It needs major surgery. I'm
willing to perform some of that surgery, but wanted to check here first.
Also, I'd like thoughts on whether I should check in my somewhat gross
version first, and then run from there.

The gross version (patch not attached because its huge and mindless, I can
if folks want) just is a pile of 'if, else if, else if...' chains through
each CPU string (and the requisite stashing of the CPU string using setCPU).

My proposed re-vamp would start by defining an enum for all of the processor
variations, and a using a single stringswitch in the setCPU routine to map
from string -> enum value. Then the if chains can become a switch with some
small ifs or sub-switches within it. This has the added advantage of
rejecting -march flags not currently understood by clang[1].

Subsequent fixing which would seem highly advantageous, and pretty easy:
1) remove the 'remove this' comment on setCPU, make it mandatory, and remove
the CPU argument to some TargetInfo routines
2) sink common state down to TargetInfo instead of having it in each
subclass
3) check in comprehensive tests for the preprocessor defines produced for
each architecture

Subsequent fixing which would be nice, but I certainly won't have time for:
move this entire thing to tablegen.

#1 above is a bit dubious... maybe there is some reason why this wasn't
pursued originally? I'd be interested to hear why.

-Chandler

[1] It's just amazing that this currently works:

% ./bin/clang -m32 -march=pimpmycpu -E -dM -x c /dev/null
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110927/d0f90816/attachment.html>