search for: mo_register

...We do seem to have a compelling reason for it in Hexagon, and I wanted to make sure that it is OK with everyone. I plan to use it for attributing target specific info to MOs and in more general case to MIs that those MOs belongs to. Part of my question would be - is it still unsafe to use it for MO_Register and if so, then why? Thanks a lot. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits- > bounces at cs.uiuc.edu] On Behalf Of Jakob S...

...pelling reason for it in Hexagon, and I wanted to > make sure that it is OK with everyone. I plan to use it for attributing > target specific info to MOs and in more general case to MIs that those MOs > belongs to. > Part of my question would be - is it still unsafe to use it for > MO_Register and if so, then why? > > Thanks a lot. > > Sergei > > --- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by > The Linux Foundation > > >> -----Original Message----- >> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commi...

...--- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Owen Anderson >> Sent: Tuesday, August 21, 2012 11:37 AM >> To: Stellard, Thomas >> Cc: llvmdev at cs.illinois.edu >> Subject: Re: [LLVMdev] No more TargetFlags on MO_Register >> MachineOperands >> >> Tom, >> >> The generally accepted way of achieving this is to leave the built-in >> pattern on the instruction empty, and to use def : Pat constructs to >> provide the default values. >> >> def : Pat<(fceil R600_Re...

> -----Original Message----- > From: Owen Anderson [mailto:resistor at mac.com] > Sent: Wednesday, August 22, 2012 11:41 AM > To: Villmow, Micah > Cc: Stellard, Thomas; llvmdev at cs.illinois.edu > Subject: Re: [LLVMdev] No more TargetFlags on MO_Register > MachineOperands > > > On Aug 22, 2012, at 11:34 AM, "Villmow, Micah" <Micah.Villmow at amd.com> > wrote: > > > > > > >> -----Original Message----- > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc....

...-----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Owen Anderson > Sent: Tuesday, August 21, 2012 11:37 AM > To: Stellard, Thomas > Cc: llvmdev at cs.illinois.edu > Subject: Re: [LLVMdev] No more TargetFlags on MO_Register > MachineOperands > > Tom, > > On Aug 21, 2012, at 11:21 AM, Tom Stellard <thomas.stellard at amd.com> > wrote: > > > I've been working on replacing the MachineOperand flags in the R600 > > backend with immediate operands, but I can't figure out how...

Arnold, I wanted to hear from Jacob is the original patch in question still needed, since our use of this field could surpass const extenders and could potentially include MO_Register. Jacob, Can you please comment? Thanks. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Arnold Schwaighofer [mailto:arnolds at codeaurora.org] > Sent: Monday, October 29, 2012 1:02 PM...

Tom, On Aug 21, 2012, at 11:21 AM, Tom Stellard <thomas.stellard at amd.com> wrote: > I've been working on replacing the MachineOperand flags in the R600 > backend with immediate operands, but I can't figure out how to modify > the instruction patterns to make this work. For example, I have the class: > > class R600_1OP <bits<32> inst, string opName,

...> > >> -----Original Message----- >> From: Owen Anderson [mailto:resistor at mac.com] >> Sent: Wednesday, August 22, 2012 11:41 AM >> To: Villmow, Micah >> Cc: Stellard, Thomas; llvmdev at cs.illinois.edu >> Subject: Re: [LLVMdev] No more TargetFlags on MO_Register >> MachineOperands >> >> Not particularly. There are backends already in existence that make >> heavy use of it. The key is that def : Pat constructs can take >> advantage of all of the same mechanisms for factoring out commonality >> that normal patterns can,...

On Mon, Aug 20, 2012 at 04:30:13PM -0700, Jakob Stoklund Olesen wrote: > All, > > The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. > > It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on

All, The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on register operands. This is because many target-independent passes are manipulating register operands

Hi all, I have a question about the types of MachineOperand. There are 12 different types of MachineOperand such as MO_Register, MO_Immediate and so on. Some of the names are self-explanatory such as MO_Register and MO_Immediate. Some of them are a little confusing such as MO_FrameIndex, MO_ConstantPoolIndex and so on. For example, what is the different between MO_ExternalSymbol and MO_GlobalAddress? Are these two types...

On Oct 29, 2012, at 3:28 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Arnold, > > I wanted to hear from Jacob is the original patch in question still needed, > since our use of this field could surpass const extenders and could > potentially include MO_Register. > > Jacob, > > Can you please comment? Thanks. I don't really have anything to add to the commit message. There aren't plans to allow target flags on register operands. Any particular reason you can't use immediates? /jakob >>>> >>>> URL: htt...

...>> 0x0000000001a0c814 in llvm::MachineOperand::isReg (this=0x7) at >>>>> /local/mnt/workspace/slarin/tools/llvm-mainline- >>>> merged/include/llvm/CodeGen/ >>>>> MachineOperand.h:204 >>>>> 204 bool isReg() const { return OpKind == MO_Register; } >>>>> (gdb) bt >>>>> #0 0x0000000001a0c814 in llvm::MachineOperand::isReg (this=0x7) at >>>>> /local/mnt/workspace/slarin/tools/llvm-mainline- >>>> merged/include/llvm/CodeGen/ >>>>> MachineOperand.h:204 >>>>&gt...

...erand&MO = MI->getOperand(OpNo); >> >> switch (MO.getType()) { >> - default: >> - assert(0&& "<unknown operand type>"); >> + default: llvm_unreachable ("<unknown operand type>"); >> case MachineOperand::MO_Register: >> O<< HexagonInstPrinter::getRegisterName(MO.getReg()); >> return; >> @@ -196,10 +196,45 @@ void HexagonAsmPrinter::printPredicateOperand(const MachineInstr *MI, >> /// the current output stream. >> /// >> void HexagonAsmPrinter::EmitIn...