[LLVMdev] Getting command line options to affect subtarget features
Hal Finkel
hfinkel at anl.gov
Thu Jan 31 10:07:34 PST 2013
----- Original Message -----
> From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvmdev at cs.uiuc.edu
> Sent: Thursday, January 31, 2013 11:40:24 AM
> Subject: Re: [LLVMdev] Getting command line options to affect subtarget features
>
> On Thu, 2013-01-31 at 11:29 -0600, Bill Schmidt wrote:
> > On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote:
> > > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote:
> > > >
> > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote:
> > > > > ----- Original Message -----
> > > > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com>
> > > > > > To: llvmdev at cs.uiuc.edu
> > > > > > Sent: Thursday, January 31, 2013 9:26:15 AM
> > > > > > Subject: [LLVMdev] Getting command line options to affect
> > > > > > subtarget features
> > > > > >
> > > > > > The problem I'm trying to solve: Invoking clang on PowerPC
> > > > > > with
> > > > > > -fno-altivec has no effect.
> > > > > >
> > > > > > From what I've been able to piece together, PPC.td
> > > > > > specifies various
> > > > > > CPUs and the processor features available on each. So for
> > > > > > example we
> > > > > > have:
> > > > > >
> > > > > > def FeatureAltivec :
> > > > > > SubtargetFeature<"altivec","HasAltivec",
> > > > > > "true",
> > > > > > "Enable Altivec
> > > > > > instructions">;
> > > > > >
> > > > > > def : Processor<"pwr7", G5Itineraries,
> > > > > > [DirectivePwr7, FeatureAltivec,
> > > > > > FeatureMFOCRF, FeatureFSqrt,
> > > > > > FeatureSTFIWX,
> > > > > > FeatureISEL, Feature64Bit /*,
> > > > > > Feature64BitRegs
> > > > > > */]>;
> > > > > >
> > > > > > During compilation the subtarget class (such as
> > > > > > PPCSubtarget) is
> > > > > > instantiated with the strings obtained from -mcpu and
> > > > > > -mattr.
> > > > > > ParseSubtargetFeatures then uses the -mcpu and -mattr
> > > > > > values to
> > > > > > determine which features to use for code generation.
> > > > > >
> > > > > > What seems problematic is that -mattr is the only way that
> > > > > > the static
> > > > > > features of the target processor can be overridden.
> > > > > >
> > > > > > It seems there must be a way for command-line parameters
> > > > > > such as
> > > > > > -fno-altivec to be used to override which processor
> > > > > > features are
> > > > > > exploited. But I can't see immediately how this should
> > > > > > work. I
> > > > > > don't
> > > > > > know whether or how the command line flags from Clang are
> > > > > > made
> > > > > > available
> > > > > > to LLVM for inspection.
> > > > > >
> > > > > > I'm sure there must be an obvious way to do this, but
> > > > > > peeking at code
> > > > > > from other targets hasn't enlightened me. Any advice for
> > > > > > how I can
> > > > > > accomplish this?
> > > > >
> > > > > Off of the top of my head...
> > > > >
> > > > > Within the current infrastructure, I think that we need to
> > > > > alter the Clang PowerPC toolchain code
> > > > > (Clang::AddPPCTargetArgs in Tools.cpp) to do something like
> > > > > this:
> > > > >
> > > > > if (Args.hasFlag(options::OPT_fno_altivec,
> > > > > options::OPT_faltivec, true)) {
> > > > > CmdArgs.push_back("-backend-option");
> > > > > CmdArgs.push_back("-mattr=-altivec");
> > > > > }
> > > >
> > > > Perfect, Hal, thanks! That makes good sense. I'll fix this
> > > > and also
> > > > bring some of the CPU handling more up-to-date (several missing
> > > > processors that ought to be in there).
> > >
> > > Well, I spoke too soon. I tried this and received the following
> > > objection:
> > >
> > > ~/src/llvm> $LLVM_INSTALL/bin/clang vectest.c -S -O3 -o vectest.s
> > > -fno-altivec
> > > clang: Unknown command line argument '-mattr=-altivec'. Try:
> > > 'clang -help'
> > > clang: Did you mean '-mxgot=-altivec'?
> > > ~/src/llvm>
> > >
> > > Yet I can do the following:
> > >
> > > ~/src/llvm> $LLVM_INSTALL/bin/llc -O3 -mattr=-altivec vectest.ll
> > > ~/src/llvm>
> > >
> > > The general mechanism seems valid since code like this exists:
> > >
> > > if (Args.hasFlag(options::OPT_mstackrealign,
> > > options::OPT_mno_stackrealign,
> > > false)) {
> > > CmdArgs.push_back("-backend-option");
> > > CmdArgs.push_back("-force-align-stack");
> > > }
> > >
> > > But it doesn't like -mattr. Anyone have thoughts why?
> >
> > I found some ideas to try in
> > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-September/017087.html.
> > Perhaps I can try pushing these tokens onto CmdArgs and then enable
> > altivec as a feature in PPCTargetInfo::setFeatureEnabled():
> >
> > -Xclang -target-feature -Xclang -altivec
> >
> > I'll give that a whirl and see what happens.
>
> Nope, that's no good either (as I probably should have expected):
>
> wschmidt at bns:~/src/llvm> $LLVM_INSTALL/bin/clang vectest.c -S -O3 -o
> vectest.s -fno-altivec
> error: unknown argument: '-Xclang -target-feature'
> error: unknown argument: '-Xclang -altivec'
> wschmidt at bns:~/src/llvm>
>
>
> I'm officially out of ideas...
This is indeed a bit convoluted. mattr is declared in llvm/CodeGen/CommandFlags.h. So is code-model, so looking at how that works...
Frontend/CompilerInvocation.cpp pulls out -mcode-model into an options structure:
Opts.CodeModel = Args.getLastArgValue(OPT_mcode_model)
Then in CodeGen/BackendUtil.cpp, this is transformed into an argument to createTargetMachine
// FIXME: Parse this earlier.
llvm::CodeModel::Model CM;
if (CodeGenOpts.CodeModel == "small") {
CM = llvm::CodeModel::Small;
} else if (CodeGenOpts.CodeModel == "kernel") {
CM = llvm::CodeModel::Kernel;
...
TargetMachine *TM = TheTarget->createTargetMachine(Triple, TargetOpts.CPU,
FeaturesStr, Options,
RM, CM, OptLevel);
I think that what we want for altivec is actually to put things into FeaturesStr. This is populated by:
std::string FeaturesStr;
if (TargetOpts.Features.size()) {
SubtargetFeatures Features;
for (std::vector<std::string>::const_iterator
it = TargetOpts.Features.begin(),
ie = TargetOpts.Features.end(); it != ie; ++it)
Features.AddFeature(*it);
FeaturesStr = Features.getString();
}
the code that puts things into Features is in Basic/Targets.cpp (to get defaults) and Driver/Tools.cpp (to get command-line options). Unfortunately, the code in Driver/Tools.cpp is in Clang::AddX86TargetArgs (and, thus, is X86 specific). It seems like some refactoring might be in order.
-Hal
>
> >
> > Bill
> >
> > >
> > > Thanks,
> > > Bill
> > >
> > > >
> > > > Thanks,
> > > > Bill
> > > >
> > > > >
> > > > > Why this not done currently I don't know.
> > > > >
> > > > > -Hal
> > > > >
> > > > > >
> > > > > > Thanks! I appreciate any help.
> > > > > >
> > > > > > Bill
> > > > > >
> > > > > > --
> > > > > > Bill Schmidt, Ph.D.
> > > > > > IBM Advance Toolchain for PowerLinux
> > > > > > IBM Linux Technology Center
> > > > > > wschmidt at us.ibm.com
> > > > > > wschmidt at linux.vnet.ibm.com
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > LLVM Developers mailing list
> > > > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > > > >
> > > > >
>
>
More information about the llvm-dev
mailing list