search for: parsesubtargetfeatures

...[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...

...t, 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 b...

...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 param...

...tureISEL, 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. &g...

...t; 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. > > > > &...

..., 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 c...

On Sat, May 7, 2011 at 4:17 AM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > Hi, Justin > > Thansk, but I have a little concern though. I saw Chiou mentioned the > compatibility issue of PTX on the mailing list. > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038654.html > > In my PTX.td patch, > > def FeaturePTX23 : SubtargetFeature<"ptx23",

Hi, Justin Thansk, but I have a little concern though. I saw Chiou mentioned the compatibility issue of PTX on the mailing list. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038654.html In my PTX.td patch, def FeaturePTX23 : SubtargetFeature<"ptx23", "PTXVersion", PTX_VERSION_2_3", "Use PTX Language Version

...fully using the MicroBlaze assembler. Many small to medium sized test cases seem to compile and work but extensive testing has not yet been done. Your patch looks very clean. Some comments: - You don't need the -mb-has-* options in MBlazeSubtarget.cpp. You can pass -mattr=+mul,-div to llc and ParseSubtargetFeatures will take care of the rest. - Please try to move your intrinsics into the target subdirectory. So far only Blackfin has done that, but we would like to keep everything target-specific in lib/Target/MBlaze. - Please use lower-case register names in assembly if the assembler allows it. - I think y...

I have been working on a LLVM backend for the MicroBlaze soft-processor: http://www.xilinx.com/tools/microblaze.htm http://en.wikipedia.org/wiki/MicroBlaze Attached is the initial MicroBlaze patch. It does the following: 1. Adds mblaze as a target in configure and configure.ac 2. Adds mblaze specific intrinsics in include/llvm/IntrinsicsMBlaze.td and include/llvm/Intrinsics.td 3. Adds mblaze

...), HasDSPR2(false), - RM(_RM) + AllowMixed16_32(Mixed16_32), + RM(_RM), OverrideMode(NoOverride), TM(_TM) { std::string CPUName = CPU; if (CPUName.empty()) @@ -42,6 +60,8 @@ MipsSubtarget::MipsSubtarget(const std::string &TT, const std::string &CPU, // Parse features string. ParseSubtargetFeatures(CPUName, FS); + PreviousInMips16Mode = InMips16Mode; + // Initialize scheduling itinerary for the specified CPU. InstrItins = getInstrItineraryForCPU(CPUName); @@ -72,3 +92,45 @@ MipsSubtarget::enablePostRAScheduler(CodeGenOpt::Level OptLevel, &Mips::CPU6...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for