Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] MachineOperand Fixed Register"
2013 May 20
0
[LLVMdev] MachineOperand Fixed Register
On May 16, 2013, at 2:23 PM, dag at cray.com wrote:
> Is there any way to determine if a Register-type MachineOperand
> represents a fixed machine register? For example, call arguments must
> end up in specific machine register but I don't see any way to ascertain
> this from the information in MachineOperand. Basically, I need to know
> if I am allowed to rename a
2013 Apr 18
4
[LLVMdev] MachineOperand SubReg
I'm working on the post-regalloc dataflow engine I mentioned yesterday.
Currently I only need to track register operands.
A MachineOperand has both a getReg() and a getSubReg() interface. For a
physical register operand, is getReg() guaranteed to be the "most super"
register with getSubReg() providing the specific subregister information
for the operand? If so then for my current
2012 Aug 06
3
[LLVMdev] Register Coalescer does not preserve TargetFlag
Do you know any backend that implement instructions as a flag modifier in instruction ?
Thank,
Vincent Lejeune
----- Mail original -----
> De : Jakob Stoklund Olesen <stoklund at 2pi.dk>
> À : Vincent Lejeune <vljn at ovi.com>
> Cc : "llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu)" <llvmdev at cs.uiuc.edu>
> Envoyé le : Lundi 6 août 2012 20h06
>
2013 Apr 19
2
[LLVMdev] MachineOperand SubReg
Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:
>> A MachineOperand has both a getReg() and a getSubReg() interface.
>> For a physical register operand, is getReg() guaranteed to be the
>> "most super" register with getSubReg() providing the specific
>> subregister information for the operand? If so then for my current
>> purposes it seems I
2010 Oct 19
0
[LLVMdev] MachineOperand::TargetFlags question
On Oct 18, 2010, at 11:59 AM, Villmow, Micah wrote:
> I’m looking at utilizing the MachineOperand::TargetFlags and I’m wondering if there is a specific reason on limiting the size of the flags to 8 bits.
We create *LOTS* of MachineOperand instances, so it needs to be as small as possible.
> Also are there any assumptions on what can be validly used here that I should keep in mind? Ideally
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 Aug 06
0
[LLVMdev] Register Coalescer does not preserve TargetFlag
On Aug 6, 2012, at 11:00 AM, Vincent Lejeune <vljn at ovi.com> wrote:
> Ok.
>
> I tried to do it using a pass after register allocation, lowering NEG/ABS instructions.
> However I met a problem : apparently getNextOperandForReg() can returns a MachineOperand before the one I'm processing.
>
> The following code snippet :
>
>
> void
2010 Oct 18
5
[LLVMdev] MachineOperand::TargetFlags question
I'm looking at utilizing the MachineOperand::TargetFlags and I'm wondering if there is a specific reason on limiting the size of the flags to 8 bits. Also are there any assumptions on what can be validly used here that I should keep in mind? Ideally I need 28 bits but I can code the major cases using all 8 bits, but I don't want to clobber anything that might be used internally in
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
2013 Apr 18
0
[LLVMdev] MachineOperand SubReg
On Apr 18, 2013, at 9:45 AM, dag at cray.com wrote:
> I'm working on the post-regalloc dataflow engine I mentioned yesterday.
> Currently I only need to track register operands.
>
> A MachineOperand has both a getReg() and a getSubReg() interface. For a
> physical register operand, is getReg() guaranteed to be the "most super"
> register with getSubReg()
2012 Aug 06
4
[LLVMdev] Register Coalescer does not preserve TargetFlag
Hi,
R600 hardware (Radeon gfx card) does neither have a NEG nor an ABS instruction ; however any sources operand can be negated/abs'd by setting a bit for every source operand in the final bytecode (but not DST).
A good way of modeling this behavior in LLVM is by using TargetFlag on operand.
Currently the R600 LLVM backend in Mesa lower NEG and ABS DAG instruction to a MOV + TargetFlag using
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
2010 Jan 15
0
[LLVMdev] <IsKill> getting from MachineOperand is just <Used> attribute from logic.
On Jan 14, 2010, at 6:39 PM, 任坤 wrote:
> But I want do some optimization after register alloction by adjusting
> register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg.
You can also look at RegisterScavenging.cpp and MachineVerifier.cpp. They are doing the same
2012 Jun 10
2
[LLVMdev] anti-dependency breaking and mask/shift dependencies
On PowerPC (at least versions which predate the mfocrf instruction),
while there are multiple independent condition registers, the only way
to move those registers into a general-purpose register is to use mfcr,
which transfers all of the (concatenated) condition registers into one
general purpose register, followed by a mask/shift operation to extract
the desired pieces.
I would like to know if
2010 Jan 15
2
[LLVMdev] <IsKill> getting from MachineOperand is just <Used> attribute from logic.
Hi,
I have ported LLC to a risc cpu. It can pass benchmark that I have at current.
But I want do some optimization after register alloction by adjusting
register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg.
R4 is marked <kill> at MBB0. If I scan R4's
2008 Sep 24
0
[LLVMdev] Determining the register type of a MachineOperand
You can get to the MachineInstr from a MachineOperand. Then get to its
TargetInstrDesc and TargetOperandInfo which has register class
information.
Evan
On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote:
> How do I determine what type of register(i.e. i32, f32, etc..) I am
> accessing from a MachineOperand? I.e. how do I get to the MVT
> struct, or equivalent information, from
2013 Apr 19
0
[LLVMdev] MachineOperand SubReg
On Apr 19, 2013, at 7:18 AM, <dag at cray.com> wrote:
> Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:
>
>>> A MachineOperand has both a getReg() and a getSubReg() interface.
>>> For a physical register operand, is getReg() guaranteed to be the
>>> "most super" register with getSubReg() providing the specific
>>> subregister
2008 Sep 24
2
[LLVMdev] Determining the register type of a MachineOperand
This only has the register class information, not the register type
information.
My register class has multiple register types and I need to know how to
differentiate which register type of my register class of the current
register.
The information in the MVT data type is what I need, i.e. the position
in the GPRVT array of each register.
Something equivalent to MVT getValueType() but for
2008 Sep 23
2
[LLVMdev] Determining the register type of a MachineOperand
How do I determine what type of register(i.e. i32, f32, etc..) I am
accessing from a MachineOperand? I.e. how do I get to the MVT struct, or
equivalent information, from a MachineOperand object?
Micah Villmow
Systems Engineer
Advanced Technology & Performance
Advanced Micro Devices Inc.
4555 Great America Pkwy,
Santa Clara, CA. 95054
P: 408-572-6219
F: 408-572-6596