Displaying 4 results from an estimated 4 matches for "mv_nimm6_ar16".
2014 Aug 22
2
[LLVMdev] Help with definition of subregisters; spill, rematerialization and implicit uses
...ranges for vreg1954:
%vreg1954 [5000r,5056r:0)[5056r,5348r:1) 0 at 5000r 1 at 5056r
And vreg1954 is mentioned in these instructions:
5000B %vreg1954:hi16<def,read-undef> = mv_any16 32766
[...]
5048B mv_ar16_r16_rmod1 %vreg1954:hi16, %vreg1753
5056B %vreg1954:lo16<def> = mv_nimm6_ar16 0
5064B Store40FI %vreg1954, <fi#2>
[...]
5128B %vreg223<def> = COPY %vreg1954
[...]
5216B %vreg1178<def> = COPY %vreg1954
[...]
5348B %vreg1955<def> = COPY %vreg1954
Then it tries to rematerialize:
Value %vreg1954:0 at 5000r may remat from %vreg1954:hi...
2014 Aug 19
2
[LLVMdev] Help with definition of subregisters; spill, rematerialization and implicit uses
Hi Quentin,
On 08/15/14 19:01, Quentin Colombet wrote:
[...]
>> The question is: How should true subregister definitions be
>> expressed so that they do not interfere with each other? See the
>> detailed problem description below.
>
> We do have a limitation in our current liveness tracking for
> sub-register. Therefore, I am not sure that is possible.
>
>
2016 Mar 04
2
PHI node to different register class vs TailDuplication
...and "aNlh_0_7" are disjoint.
Is such a PHI node ok?
If it is, then there is a bug in TailDuplication.
Before TailDuplication we have:
BB#2: derived from LLVM BB %bb2
Predecessors according to CFG: BB#1
%vreg12<def> = mv16Sym <ga:@a>; rN:%vreg12
%vreg13<def> = mv_nimm6_ar16 0; aNlh_rN:%vreg13
mv_ar16_r16_rmod1 %vreg13<kill>, %vreg12<kill>; aNlh_rN:%vreg13 rN:%vreg12
brr_uncond <BB#4>;
Successors according to CFG: BB#4(?%)
BB#4: derived from LLVM BB %bb4
Predecessors according to CFG: BB#2 BB#3
%vreg2<def> = PHI %vreg0, <BB#2>...
2014 Aug 15
2
[LLVMdev] Help with definition of subregisters; spill, rematerialization and implicit uses
...:
"Value Reg5:0 at 5000r may remat from Reg5:hi16<def,read-undef> = mv_any16
32766"
So it says Reg5 can be rematerialized by setting it's high part...
We also get:
reload: 5052r Reg5<def> = Load40FI <fi#2>
rewrite: 5056r Reg5:lo16<def> = mv_nimm6_ar16 0
So it inserts a reload of the full Reg5 prior to the setting of
Reg5:lo16, because it thinks there is an implicit use of Reg5 when
writing the low part??? This seems very weird to me.
The decision is based on the fact that MachineOperand::readsReg()
returns true:
/// readsReg - Returns tru...