Anemic support for processor based preprocessor defines

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

Hi Chandler,

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.

Can we somehow tablegen'ify these defines?

We can, but they were quite easy to lay out by hand. It’s not clear to me that its worth the effort to teach tablegen about them unless we want to move all the architectures over, and expect the whole thing to grow a lot…

We can, but they were quite easy to lay out by hand. It's not clear to me
that its worth the effort to teach tablegen about them unless we want to
move all the architectures over, and expect the whole thing to grow a lot...

Well... we can just autogenerate all those switches, etc. and reduce
the "weight" of the source file....

On general principle, please try macro-metaprogramming before adding yet another tblgen mode. If it's not worth a macro-metaprogram, it's definitely not worth tblgen.

John.

I completely agree. Currently, I don’t think it’s worth that. If I go in to modify a bunch of stuff again, I could look at this, but I’m not sure it will really help much.

In particular, the switches are hard to hide. They include a lot of one-off and quirky behavior in order to correctly model GCC’s behavior on old chips. (For example, see the k6, k6-2, and k6-3 silliness…)