search for: mcsubtargetinfo

...tem_platform.dylib 0x0000000000000002 _sigtramp + 2032693506 5 llvm-mc 0x00000001096a5836 abort + 22 6 llvm-mc 0x00000001096a5811 __assert_rtn + 81 7 llvm-mc 0x000000010963f4e8 llvm::SparcInstPrinter::printOperand(llvm::MCInst const*, int, llvm::MCSubtargetInfo const&, llvm::raw_ostream&) + 136 8 llvm-mc 0x000000010963eae0 llvm::SparcInstPrinter::printInstruction(llvm::MCInst const*, llvm::MCSubtargetInfo const&, llvm::raw_ostream&) + 256 9 llvm-mc 0x000000010964f5e6 llvm::SparcInstPrinter::printInst(llv...

...mp + 2032693506 >> 5 llvm-mc 0x00000001096a5836 abort + 22 >> 6 llvm-mc 0x00000001096a5811 __assert_rtn + 81 >> 7 llvm-mc 0x000000010963f4e8 >> llvm::SparcInstPrinter::printOperand(llvm::MCInst const*, int, >> llvm::MCSubtargetInfo const&, llvm::raw_ostream&) + 136 >> 8 llvm-mc 0x000000010963eae0 >> llvm::SparcInstPrinter::printInstruction(llvm::MCInst const*, >> llvm::MCSubtargetInfo const&, llvm::raw_ostream&) + 256 >> 9 llvm-mc 0x000000010964f5e6 &...

...000000000002 _sigtramp + 2032693506 > 5 llvm-mc 0x00000001096a5836 abort + 22 > 6 llvm-mc 0x00000001096a5811 __assert_rtn + 81 > 7 llvm-mc 0x000000010963f4e8 > llvm::SparcInstPrinter::printOperand(llvm::MCInst const*, int, > llvm::MCSubtargetInfo const&, llvm::raw_ostream&) + 136 > 8 llvm-mc 0x000000010963eae0 > llvm::SparcInstPrinter::printInstruction(llvm::MCInst const*, > llvm::MCSubtargetInfo const&, llvm::raw_ostream&) + 256 > 9 llvm-mc 0x000000010964f5e6 > llvm::SparcI...

...>> 5 llvm-mc 0x00000001096a5836 abort + 22 >>> 6 llvm-mc 0x00000001096a5811 __assert_rtn + 81 >>> 7 llvm-mc 0x000000010963f4e8 >>> llvm::SparcInstPrinter::printOperand(llvm::MCInst const*, int, >>> llvm::MCSubtargetInfo const&, llvm::raw_ostream&) + 136 >>> 8 llvm-mc 0x000000010963eae0 >>> llvm::SparcInstPrinter::printInstruction(llvm::MCInst const*, >>> llvm::MCSubtargetInfo const&, llvm::raw_ostream&) + 256 >>> 9 llvm-mc 0x00...

Jim, You are correct: MipsSubtarget. For llvm-mc we have a straight MCSubtargetInfo object. For llc we get a MipsSubtarget object which derives from MipsGenSubtargetInfo which derives from TargetSubtargetInfo which derives from MCSubtargetInfo. The patch I hope to send out for review will do this: Add a new data member to MCSubtargetInfo base class. It will be a set of integers...

...ou only have hwdiv in one mode). --Sumanth G -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Tuesday, January 27, 2015 6:44 PM To: Sumanth Gundapaneni Cc: LLVM Developers Mailing List; Roman Divacky; Ana Pazos Subject: Re: [LLVMdev] CPUStringIsValid() into MCSubtargetInfo and use it for ARM .cpu parsing Hi Sumanth, > Shouldn’t the eabi attributes be honored ? EABI attributes are instructions for the linker on which object files are compatible with each other, not instructions for the assembler (and trying to make them so sounds like a recipe for confusion to m...

On 29 January 2015 at 03:36, Tim Northover <t.p.northover at gmail.com> wrote: > These ought to be unneeded if you do 1+2 above. As far as I remember, .arch_extension does change the assembler flags to support whatever you set. Have you tried that? cheers, --renato

...--Sumanth G > -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > Sent: Thursday, January 29, 2015 9:03 AM > To: Tim Northover > Cc: Sumanth Gundapaneni; Roman Divacky; LLVM Developers Mailing List > Subject: Re: [LLVMdev] CPUStringIsValid() into MCSubtargetInfo and use it > for ARM .cpu parsing > > On 29 January 2015 at 03:36, Tim Northover <t.p.northover at gmail.com> > wrote: >> These ought to be unneeded if you do 1+2 above. > > As far as I remember, .arch_extension does change the assembler flags to > support whatever...

Hi Divacky, I have an armv7 variant that supports hardware division (extension). For my variant, I use ".cpu cortex-a9" and division attribute(.eabi_attribute 44, 2 @ Tag_DIV_use) to let the assembler do the right thing if it encounters a division instruction. With your path, the .cpu directive is used to fetch the available features of a CPU and ignores the eabi attributes. What

...ride { >> return &Subtarget; >> } > > Ok, so BPF and Lanai initialize a BPFSubtarget and LanaiSubtarget in > the initializer list for BPFTargetMachine and LanaiTargetMachine. I'm > not sure I quite follow your concern about initAsmInfo, as that > accesses an MCSubtargetInfo rather than a subclass of Subtarget. The following is what I observed: Both Subtarget constructor and initAsmInfo will eventually create a MCSubtargetInfo, which calls InitMCProcessorInfo. void MCSubtargetInfo::InitMCProcessorInfo(StringRef CPU, StringRef FS) { FeatureBits = getFeatures(CPU, FS...

> How about the below option ? My options were mutually exclusive, or at least any one of them would allow you to assemble code using sdiv/udiv. You probably don't need to combine them. > 1. Specify an existing generic armv7 CPU or the CPU which is close my custom variant. My custom variant can be treated as "cortex-a9" + hwdiv. So my CPU here is "cortex-a9" > 2.

...:0 #8 0x0000000000c08966 llvm::X86II::getSizeOfImm(unsigned long) lib/Target/X86/MCTargetDesc/X86BaseInfo.h:577:29 #9 0x0000000000c04c2a (anonymous namespace)::X86MCCodeEmitter::encodeInstruction(llvm::MCInst const&, llvm::raw_ostream&, llvm::SmallVectorImpl<llvm::MCFixup>&, llvm::MCSubtargetInfo const&) const lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1512:67 #10 0x00000000015884b3 llvm::MCELFStreamer::EmitInstToData(llvm::MCInst const&, llvm::MCSubtargetInfo const&) lib/MC/MCELFStreamer.cpp:478:26 #11 0x00000000015aadc0 llvm::MCObjectStreamer::EmitInstruction(llvm::MCIns...

..._________________ From: Carter, Jack Sent: Tuesday, December 11, 2012 1:33 PM To: Jim Grosbach Cc: Rafael Espíndola; List Subject: RE: [LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter Jim, You are correct: MipsSubtarget. For llvm-mc we have a straight MCSubtargetInfo object. For llc we get a MipsSubtarget object which derives from MipsGenSubtargetInfo which derives from TargetSubtargetInfo which derives from MCSubtargetInfo. The patch I hope to send out for review will do this: Add a new data member to MCSubtargetInfo base class. It will be a set of integers...

...strings) from MCTargetDesc./ I see that in lib/Target/ARM/ARM.td all the features have been removed from Proc definition (e.g.: ProcA9) and added to ProcessorModel definition (e.g.: ProcessorModel<"cortex-a9"). But I find that the features from Proc are still being read and set in MCSubtargetInfo through the ARMFeatureKV table. So if the Proc is empty the corresponding feature is not being set. In my case, if I add FeatureFP16 back to the ProcA9 definition in ARM.td I get back all the lost performance. Could you please give me some insight on how, after your change, do the Proc features...

...e standalone one. But the 2 gather information that ends up in the ELF header in different ways such as assembler directives in the standalone assembler such as ".options pic0" which forces non-shared relocation model. > > The direction I am going in is to add a new data member in MCSubtargetInfo that is a std::set. This set of booleans are target specific and is used as a bulletin board. This allows me to update my MipsSubtargetInfo object whenever it or a derived reference of it is available. I have a reference of SubtargetInfo in <target>ELFObjectWriter in my current patch. I don...

...well as the standalone one. But the 2 gather information that ends up in the ELF header in different ways such as assembler directives in the standalone assembler such as ".options pic0" which forces non-shared relocation model. The direction I am going in is to add a new data member in MCSubtargetInfo that is a std::set. This set of booleans are target specific and is used as a bulletin board. This allows me to update my MipsSubtargetInfo object whenever it or a derived reference of it is available. I have a reference of SubtargetInfo in <target>ELFObjectWriter in my current patch. I am...

...nSubtargetInfo.inc./ Here the ProcA9 features appear in /ARMFeatureKV/ table: /{ "a9", "Cortex-A9 ARM processors", { ARM::ProcA9 }, { *ARM::FeatureFP16* } }, /With your change, the features for ProcA9 in the above entry are empty.//This ARMFeatureKV table is then read in MC/MCSubtargetInfo.cpp in the getFeatures() function. Thanks, Mandeep On 2/24/2016 2:42 AM, Bradley Smith wrote: > > Hi, > > The idea behind that change was to make ARM.td clearer, that is, > adding architecture features to new architecture subtarget features, > and to have the CPUs inherit fro...

...64c06 llvm::X86ATTInstPrinter::printInstruction(llvm::MCInst const*, llvm::raw_ostream&) /home/shenyouren/workspace/build-llvm/lib/Target/X86/X86GenAsmWriter.inc:48204:0 #13 0x0000000002668edc llvm::X86ATTInstPrinter::printInst(llvm::MCInst const*, llvm::raw_ostream&, llvm::StringRef, llvm::MCSubtargetInfo const&) /home/shenyouren/workspace/llvm/lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp:89:0 #14 0x00000000031d5811 llvm::MCTargetStreamer::prettyPrintAsm(llvm::MCInstPrinter&, llvm::raw_ostream&, llvm::MCInst const&, llvm::MCSubtargetInfo const&) /home/shenyouren/workspace/llv...

...etting the complete > > set of ABI information to every part of LLVM that needs it and you are saying > > TargetMachine should encapsulate that data directly. > Essentially. To be more precise I'm saying that TargetMachine (or an MC level equivalent > - see TargetSubtargetInfo/MCSubtargetInfo) should encapsulate everything that's needed > from the object level down for any particular target. That sounds like TargetTuple but spelt something like MCTargetMachine. It sounds like MCTargetMachine should usurp the Triple in the places it exists in the MC layer (and maybe be introduced...

Hi, I found some different discrepancy on how Subtarget is created between some arch specific TargetMachine constructor. For example, for BPF/Lanai: BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options,