search for: sub_lo

...anaka: > Hi, > > I have a question about the way sub-registers are spilled and restored > that is related to the changes I made in r192119. > > Suppose I have the following piece of code with four > instructions. %vreg0 and %vreg1 consist of two sub-registers indexed > by sub_lo and sub_hi. > > instr0 %vreg0<def> > instr1 %vreg1:sub_lo<def,read-undef> > instr2 %vreg0<use> > instr3 %vreg1:sub_hi<def> > > If register allocator decides to insert spill and restore instructions > for %vreg0, will it spill the whole register that...

...: > > Hi, > > I have a question about the way sub-registers are spilled and restored > that is related to the changes I made in r192119. > > Suppose I have the following piece of code with four > instructions. %vreg0 and %vreg1 consist of two sub-registers indexed by > sub_lo and sub_hi. > > instr0 %vreg0<def> > instr1 %vreg1:sub_lo<def,read-undef> > instr2 %vreg0<use> > instr3 %vreg1:sub_hi<def> > > If register allocator decides to insert spill and restore instructions > for %vreg0, will it spill the whole register th...

...a: >> Hi, >> >> I have a question about the way sub-registers are spilled and restored that is related to the changes I made in r192119. >> >> Suppose I have the following piece of code with four instructions. %vreg0 and %vreg1 consist of two sub-registers indexed by sub_lo and sub_hi. >> >> instr0 %vreg0<def> >> instr1 %vreg1:sub_lo<def,read-undef> >> instr2 %vreg0<use> >> instr3 %vreg1:sub_hi<def> >> >> If register allocator decides to insert spill and restore instructions for %vreg0, will it spill...

I've been working on patches to improve subregister liveness tracking on llvm and I wanted to inform the llvm community about the overal design/motivation for them. I will send the patches to llvm-commits later today. Greetings Matthias Braun Subregisters in llvm ==================== Some targets can access registers in different ways resulting in wider or narrower accesses. For

...1, $A, $B), (G_SUB $D2, $A, $B)), (apply (BUTTERFLY $D1, $D2, $A, $B))>; def : GICombineRule< (defs reg:$D, reg:$A, reg:$B), (match (G_TRUNC s32:$t1, s64:$A), (G_TRUNC s32:$t2, s64:$B), (G_ADD $D, $t1, $t2), (apply (ADD32 $D, (sub_lo $A), (sub_lo $B)))>; // This one keeps the def of $D/$A because we wanted operand instead of reg. We didn't have // anything requiring that though and could trivially change them to reg. def : GICombineRule< (defs operand:$D, operand:$A), (match (G_LOAD $D, $A):$MI...

...registers. We use subregister indexes to specify that it's a subregister that should be emitted by the apply step. def : GICombineRule< (defs reg:$D, reg:$A, reg:$B), (match (G_TRUNC s32:$t1, s64:$A), (G_TRUNC s32:$t2, s64:$B), (G_ADD $D, $t1, $t2), (apply (ADD32 $D, (sub_lo $A), (sub_lo $B)))>; Matching MachineMemOperands While re-writing these examples, I also realized I didn't have any examples for testing properties of the MachineMemOperand, so here's one: def mmo_is_load_8 : GIMatchPredicate< (ins instr:$A), (outs), [{ if (!${A}....

...it's a subregister that should be emitted by the apply step. >> def : GICombineRule< >> (defs reg:$D, reg:$A, reg:$B), >> (match (G_TRUNC s32:$t1, s64:$A), >> (G_TRUNC s32:$t2, s64:$B), >> (G_ADD $D, $t1, $t2), >> (apply (ADD32 $D, (sub_lo $A), (sub_lo $B)))>; >> _Matching MachineMemOperands_ >> While re-writing these examples, I also realized I didn't have any examples for testing properties of the MachineMemOperand, so here's one: >> def mmo_is_load_8 : GIMatchPredicate< >> (ins in...

..., $B), >> (G_SUB $D2, $A, $B)), >> (apply (BUTTERFLY $D1, $D2, $A, $B))>; >> def : GICombineRule< >> (defs reg:$D, reg:$A, reg:$B), >> (match (G_TRUNC s32:$t1, s64:$A), >> (G_TRUNC s32:$t2, s64:$B), >> (G_ADD $D, $t1, $t2), >> (apply (ADD32 $D, (sub_lo $A), (sub_lo $B)))>; >> // This one keeps the def of $D/$A because we wanted operand instead of reg. We didn't have >> // anything requiring that though and could trivially change them to reg. >> def : GICombineRule< >> (defs operand:$D, operand:$A), >&g...

...iple pieces using !con, etc.). That makes sense to me. >> Another issue we didn't like with DAG is that you also end up needing a lot of pseudo-nodes like EXTRACT_SUBREG whereas these are natural parts of the MIR syntax. For example: >> (set $d, (EXTRACT_SUBREG (MYTGT_ADD $A, $B), sub_lo)) >> compared to: >> %d:sub_lo = MYTGT_ADD %A, %B >> and: >> (set $d, (REG_SEQUENCE GPR32, (MYTGT_ADD $A, $B), sub_lo, (MYTGT_ADD $C, $D), sub_hi)) >> compared to: >> %d:sub_lo = MYTGT_ADD %A, %B >> %d:sub_hi = MYTGT_ADD %C, %D > > How about: > &...

..., (G_SEXT $D2, $T2)] and at that point, we're very nearly at MIR. Another issue we didn't like with DAG is that you also end up needing a lot of pseudo-nodes like EXTRACT_SUBREG whereas these are natural parts of the MIR syntax. For example: (set $d, (EXTRACT_SUBREG (MYTGT_ADD $A, $B), sub_lo)) compared to: %d:sub_lo = MYTGT_ADD %A, %B and: (set $d, (REG_SEQUENCE GPR32, (MYTGT_ADD $A, $B), sub_lo, (MYTGT_ADD $C, $D), sub_hi)) compared to: %d:sub_lo = MYTGT_ADD %A, %B %d:sub_hi = MYTGT_ADD %C, %D Along the same lines, I also think that the integrated debug-info is only really practi...

Hi All, I've been working on the GlobalISel combiner recently and I'd like to share the plan for how Combine Rules will be defined in GlobalISel and solicit feedback on it. This email ended up rather long so: TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to.