This is an archive of the discontinued LLVM Phabricator instance.

[x86 TargetInfo] Pull CPU handling for the x86 TargetInfo into a .def file.
AbandonedPublic

Authored by erichkeane on Nov 1 2017, 4:41 PM.

Details

Summary

In anticipation of multiversioned target support (and just for
code sanity), this patch extracts as much of the X86 TargetInfo
CPU values into its own file, unifying the support.

This has the side-effect of being a touch more liberal in what it
accepts than GCC, though will normalize all values to the backend
to a much smaller list.

Note that this depends on a llvm change to 86.td that Craig promises
he'll do in the near future.

Diff Detail

Event Timeline

erichkeane created this revision.Nov 1 2017, 4:41 PM
rsmith added a subscriber: rsmith.Nov 1 2017, 5:40 PM

Thanks, this looks like a nice cleanup. I wonder of some of the switches over CPUKind (setting default features and macros) could also be moved into the .def file, but let's get this landed first and then see if that looks like an improvement.

lib/Basic/Targets/X86.h
103–106

Our convention is for the .def files to be callee-cleanup: the .def file should #undef all the macros it takes as input, rather than them being #undef'd by the #includer.

113–126

Use a struct here rather than a pair/tuple of unsigned.

lib/CodeGen/CGCall.cpp
1893

Is this part of the refactoring or a separate change?

Thanks, this looks like a nice cleanup. I wonder of some of the switches over CPUKind (setting default features and macros) could also be moved into the .def file, but let's get this landed first and then see if that looks like an improvement.

Thanks for the feedback Richard! For the CPUKind features, I'm hoping to talk @craig.topper into exposing those somehow from llvm, and just grabbing them there :) Additionally, he has some other ideas that we're going over on how to expose the CpuIs information from LLVM, rather than have version of the list here.

SO, this patch might get a bit of a diet sometime tomorrow.

Thanks!
-Erich

lib/Basic/Targets/X86.h
103–106

Ah, i missed that! Will do.

113–126

I can do that... the only real issue is attempting to keep that generic enough that other processors can use it.

lib/CodeGen/CGCall.cpp
1893

This is a part of this refactoring. The 'alias' system that this patch creates would end up leaking into the backend, so this normalizes back to the non-aliased versions.

Re-ran clang-format, which now has more sane decisions in CGBuiltin.cpp

erichkeane abandoned this revision.Nov 14 2017, 3:53 PM

First, updated this incorrectly. Second, going to do this work over a few patches to take advantage of work that Craig did in the backend.