Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] MachineOperand type"
2004 Jun 17
2
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
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
2004 Jun 17
0
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
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
>
2012 Oct 29
3
[LLVMdev] [llvm-commits] [llvm] r162770 - in /llvm/trunk: include/llvm/CodeGen/MachineOperand.h lib/CodeGen/MachineInstr.cpp
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
2012 Oct 29
0
[LLVMdev] [llvm-commits] [llvm] r162770 - in /llvm/trunk: include/llvm/CodeGen/MachineOperand.h lib/CodeGen/MachineInstr.cpp
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
2012 Oct 29
2
[LLVMdev] [llvm-commits] [llvm] r162770 - in /llvm/trunk: include/llvm/CodeGen/MachineOperand.h lib/CodeGen/MachineInstr.cpp
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
2012 Oct 29
0
[LLVMdev] [llvm-commits] [llvm] r162770 - in /llvm/trunk: include/llvm/CodeGen/MachineOperand.h lib/CodeGen/MachineInstr.cpp
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
2012 Aug 22
0
[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.edu]
>> On Behalf Of Owen Anderson
>> Sent: Tuesday, August 21, 2012 11:37 AM
>> To: Stellard, Thomas
>> Cc: llvmdev at cs.illinois.edu
>>
2012 Aug 22
2
[LLVMdev] No more TargetFlags on MO_Register MachineOperands
> -----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
2012 Aug 22
1
[LLVMdev] No more TargetFlags on MO_Register MachineOperands
> -----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
2004 Jun 18
3
[LLVMdev] MachineOperand: GlobalAddress vs. ExternalSymbol
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.
2009 Jan 23
1
[LLVMdev] How to determine Immediate Type in MachineOperand class?
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
2015 Jun 16
2
[LLVMdev] Replacing a Reg MachineOperand with a non-Reg MachineOperand?
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
2009 May 06
0
[LLVMdev] Question on tablegen
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
2009 May 08
2
[LLVMdev] Question on tablegen
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 <-
2015 Jun 16
2
[LLVMdev] Replacing a Reg MachineOperand with a non-Reg MachineOperand?
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
2012 Aug 21
2
[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 to modify
> the instruction patterns to make this work. For example, I have the class:
>
> class R600_1OP <bits<32> inst, string opName,
2009 May 08
0
[LLVMdev] Question on tablegen
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
2012 Aug 22
0
[LLVMdev] No more TargetFlags on MO_Register MachineOperands
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
2009 May 06
2
[LLVMdev] Question on tablegen
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
2015 Jun 16
2
[LLVMdev] Replacing a Reg MachineOperand with a non-Reg MachineOperand?
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