Changeset View
Standalone View
include/llvm/CodeGen/CommandFlags.h
Show First 20 Lines • Show All 225 Lines • ▼ Show 20 Lines | JTableType("jump-table-type", | ||||
clEnumValN(JumpTable::Arity, "arity", | clEnumValN(JumpTable::Arity, "arity", | ||||
"Create one table per number of parameters."), | "Create one table per number of parameters."), | ||||
clEnumValN(JumpTable::Simplified, "simplified", | clEnumValN(JumpTable::Simplified, "simplified", | ||||
"Create one table per simplified function type."), | "Create one table per simplified function type."), | ||||
clEnumValN(JumpTable::Full, "full", | clEnumValN(JumpTable::Full, "full", | ||||
"Create one table per unique function type."), | "Create one table per unique function type."), | ||||
clEnumValEnd)); | clEnumValEnd)); | ||||
cl::opt<DebuggerKind> | |||||
DebuggerTuning("debugger-tune", | |||||
probinson: Maybe this should be "debugger-tune" instead of "target" so that it implies smaller kinds of… | |||||
Not Done ReplyInline ActionsWhat's the command line argument for? I mean convenience of testing LLVM, a bit, but in general we don't want to use backend options like this when actually interacting with LLVM from Clang and other frontends. This should probably end up as a part of the CU debug info metadata? Or a module-level debug info metadata flag? (ala DWARF version) dblaikie: What's the command line argument for? I mean convenience of testing LLVM, a bit, but in general… | |||||
Not Done ReplyInline ActionsThe command line option is precisely for testing; it is not how Clang communicates to LLVM. probinson: The command line option is precisely for testing; it is not how Clang communicates to LLVM. | |||||
Not Done ReplyInline ActionsDavid pointed out in email that using a TargetOptions field, it is hard to test that Clang got it right, and might not play nicely with LTO. I'll look at doing it with module-level metadata. probinson: David pointed out in email that using a TargetOptions field, it is hard to test that Clang got… | |||||
Not Done ReplyInline ActionsModule level metadata is a possibility if we think it's something that we'll need to make sure stays consistent at LTO time etc. You'll need to define a way for the metadata to merge, etc. I don't necessarily like encoding the data this way, but without a later LTO codegen pass we can pass options to it's your best bet. echristo: Module level metadata is a possibility if we think it's something that we'll need to make sure… | |||||
cl::desc("Tune debug info for a particular debugger"), | |||||
cl::init(DebuggerKind::Default), | |||||
cl::values( | |||||
clEnumValN(DebuggerKind::GDB, "gdb", "gdb"), | |||||
clEnumValN(DebuggerKind::LLDB, "lldb", "lldb"), | |||||
clEnumValN(DebuggerKind::SCE, "sce", | |||||
"SCE targets (e.g. PS4)"), | |||||
clEnumValEnd)); | |||||
// Common utility function tightly tied to the options listed here. Initializes | // Common utility function tightly tied to the options listed here. Initializes | ||||
// a TargetOptions object with CodeGen flags and returns it. | // a TargetOptions object with CodeGen flags and returns it. | ||||
static inline TargetOptions InitTargetOptionsFromCodeGenFlags() { | static inline TargetOptions InitTargetOptionsFromCodeGenFlags() { | ||||
TargetOptions Options; | TargetOptions Options; | ||||
Options.LessPreciseFPMADOption = EnableFPMAD; | Options.LessPreciseFPMADOption = EnableFPMAD; | ||||
Options.AllowFPOpFusion = FuseFPOps; | Options.AllowFPOpFusion = FuseFPOps; | ||||
Options.Reciprocals = TargetRecip(ReciprocalOps); | Options.Reciprocals = TargetRecip(ReciprocalOps); | ||||
Options.UnsafeFPMath = EnableUnsafeFPMath; | Options.UnsafeFPMath = EnableUnsafeFPMath; | ||||
Show All 11 Lines | static inline TargetOptions InitTargetOptionsFromCodeGenFlags() { | ||||
Options.PositionIndependentExecutable = EnablePIE; | Options.PositionIndependentExecutable = EnablePIE; | ||||
Options.UseInitArray = !UseCtors; | Options.UseInitArray = !UseCtors; | ||||
Options.DataSections = DataSections; | Options.DataSections = DataSections; | ||||
Options.FunctionSections = FunctionSections; | Options.FunctionSections = FunctionSections; | ||||
Options.UniqueSectionNames = UniqueSectionNames; | Options.UniqueSectionNames = UniqueSectionNames; | ||||
Options.MCOptions = InitMCTargetOptionsFromFlags(); | Options.MCOptions = InitMCTargetOptionsFromFlags(); | ||||
Options.JTType = JTableType; | Options.JTType = JTableType; | ||||
Options.DebuggerTuning = DebuggerTuning; | |||||
Options.ThreadModel = TMModel; | Options.ThreadModel = TMModel; | ||||
return Options; | return Options; | ||||
} | } | ||||
static inline std::string getCPUStr() { | static inline std::string getCPUStr() { | ||||
// If user asked for the 'native' CPU, autodetect here. If autodection fails, | // If user asked for the 'native' CPU, autodetect here. If autodection fails, | ||||
▲ Show 20 Lines • Show All 56 Lines • Show Last 20 Lines |
Maybe this should be "debugger-tune" instead of "target" so that it implies smaller kinds of differences. It's certainly a lot less radical than most uses of "target" within LLVM.