similar to: [LLVMdev] MachineOperand type

Hi, here I am again with "why is this so" kind of a question. Among different types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. For MO_GlobalAddress, we can get usefull information from the getGlobal() method, which returns GlobalValue*. Wouldn'it it be better is MO_GlobalAddress be called MO_GlobalValue, for consistency? Second, MO_ExternalSymbol is used

On Thu, 17 Jun 2004, Vladimir Prus wrote: > > Hi, > here I am again with "why is this so" kind of a question. Among different > types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. > > For MO_GlobalAddress, we can get usefull information from the getGlobal() > method, which returns GlobalValue*. Wouldn'it it be better is >

Jakob and anyone else who might be interested... Base on this patch back in August, I sense some need to double check with you whether it is OK to start making a heavy use of MachineOperand TargetFlags? 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

Hi Sergei, our use of target flags will be on immediate register operands if I am not mistaken (and if not we can always encode it as such)? I guess you are refering to the hexagon backend needing to distinguish between instances of an instruction that uses a constant value that can fit into the 4 byte of the instruction and one that encodes the immediate in an extra instruction slot (what we

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

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

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.edu] >> On Behalf Of Owen Anderson >> Sent: Tuesday, August 21, 2012 11:37 AM >> To: Stellard, Thomas >> Cc: llvmdev at cs.illinois.edu >>

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

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

Chris Lattner wrote: > > Second, MO_ExternalSymbol is used for storing name of external > > variable/function, right? Why it's not possible to use MO_GlobalAddress, > > where returned GlobalValue* has isExternal set to true? The > > GlobalValue::getName would return the name of the symbol. > > Using the GlobalValue is certainly the preferred way if you have it.

Hi,    I would like to get the type of immediate value (integer) from MachineOperand Class. Currently the immediate value is being represented as int64_t. int64_t ImmVal; // For MO_Immediate.   Is it possible to find out whether the immediate value is int8, 16, 32 etc?   Note: My target has a virtual Instruction set.   Thanks in advance, -Sanjay -------------- next part -------------- An

I'm not sure I understand what your problem is, but are you calling the removeRegOperandFromUseList on the machine operand after changing it to GA? You have to call removeRegOperandFromUseList before changing the operand's type, as it expects a register operand. 2015-06-16 10:05 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > @Alex: Thanks. setOffset(0) eliminated any previous

One way to do this is to handle this in the AsmPrinter, with operand modifiers. For example, on x86 there are instructions with ${dst:call} in their asm string. The "call" part is interpreted as an operand modifier. The assembly printer looks for the "call" modifier on MachineOperand::MO_Immediate operands (in X86ATTAsmPrinter::printOperand), which lets it perform custom

Dan, Thanks a lot. Using a modifier in the assembly string works for this case. I am trying to solve a related problem. I am trying to print out a set of "mov" ops for the vector_shuffle node. Since the source of the "mov" is from one of the sources to vector_shuffle, depending on the mask, I am not sure what assembly string to emit. For example, if I have d <-

Hey Ryan, You end with a large constant immediate offset value because the register operand stores the register id in a union together with the offset that's used by the global address operand. Just add 'setOffset(0)' to your change method and that should solve your problem. 2015-06-16 9:15 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > So I have this for

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,

Manjunath, I had a very similar problem and I solved it using a custom vector shuffle and addition instead of mov. For example, Vector_shuffle s1, s2, <0,3> is mapped to a custom instruction where I transform the swizzle to a 32bit integer mask and an inverted mask. So I have dst, src0, src1, imm1, imm2 And I have my asm look similar to: Add dst, src0.imm1, src1.imm2 and then in the asm

On Aug 22, 2012, at 11:52 AM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > >> -----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

Hello, I am trying to create a machine instruction for "extractelement". I want to translate r <- extractelement v, 0 to mov r, v.x I was looking at the dag I can use and I found vector_extract. The inputs for this SDnode are a register and a iPtr constant. With that, I need to create 4 separate def's to extract element 0, 1, 2, and 3 and translate to v.x, v.y, v.z, and v.w. I

Tom, My current example is a global address; however, it could be any operand in theory. The arch allows for direct mem op support for ex instructions, so it could be any type of address or any type of imm or any type of register. For example, we are using intrinsics for some instructions since LLVM does not support them. Table gen does not allow for matching to direct mem op because the