-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
support LLVM subtargets #1879
Copy link
Copy link
Closed
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-codegenArea: Code generationArea: Code generationA-driverArea: rustc_driver that ties everything together into the `rustc` compilerArea: rustc_driver that ties everything together into the `rustc` compilerC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.
Description
Metadata
Metadata
Assignees
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-codegenArea: Code generationArea: Code generationA-driverArea: rustc_driver that ties everything together into the `rustc` compilerArea: rustc_driver that ties everything together into the `rustc` compilerC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Currently we generate code for LLVM targets with target-specific features (subtargets, use of specific ISA features) on or off based on defaults. In some cases the defaults are ok, sometimes they're sniffed from the host (!) but in any case the user has no way to do something like "build me an x86 binary with no SSE".
This matters for old hardware, and will matter much more when targeting phones.
Also the bots should be modified to build snapshots using the narrowest subtarget they can specify, so we can support self-hosting on the oldest hardware people happen to have. This was hit when @andrewjbaker tried to build stage1 on an older AMD Socket-A (pre-SSE2) chip. It's old but it's not that old. We should continue to at least work there.
This piece has some driver work and some convert-to-strings-that-LLVM-understands work.
The driver work consists of taking
-m<foo>and-mno-<foo>flags on the command line for individual CPU features, as well as-march=<foo>,-mcpu=<cpu>and-mabi=<abi>abbreviations that set-m<foo>feature flags collectively by more friendly arch/cpu names.Take a look in clang's command-line options file as well as its target file that translates down to LLVM-specific features. This is currently a jumble. Everyone knows it's a jumble. Rationalizing it will take a lot of work and we can't do it ahead of a drive to do so on the part of the LLVM and clang maintainers. We're along for the ride.
Look at, say,
X86TargetInfoin:http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?view=markup
And the various
-mfooflags in:http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?view=markup
http://nondot.org/sabre/LLVMNotes/TargetSpec.txt