search for: tracksliv

...un-pass=machine-scheduler -o - -verify-misched foo.mir # Before machine scheduling. ********** INTERVALS ********** %0 [16r,16d:1)[32r,32d:0) 0 at 32r 1 at 16r weight:0.000000e+00 RegMasks: ********** MACHINEINSTRS ********** # Machine code for function multiple_connected_components_dead: NoPHIs, TracksLiveness 0B bb.0: 16B dead %0:vgpr_32 = V_MOV_B32_e32 0, implicit $exec 32B dead %0:vgpr_32 = V_MOV_B32_e32 1, implicit $exec # End machine code for function multiple_connected_components_dead. *** Bad machine code: Multiple connected components in live interval *** - fun...

...3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15 )>; ===== Instruction selection ends: ... t8: i32 = ADDrr t37, t32 ... Instruction Selection correct : i32 = ADDrr i32, i32 *** MachineFunction at end of ISel *** # Machine code for function _Z11scalar_loopPsS_ss: IsSSA, TracksLiveness ... %31:sfgpr32 = ADDrr killed %32:sgpr32, %27:sgpr32 ... Here should not select f32 sfgpr32 register, debugger point to TargetRegisterInfo:: getCommonSubClass(const TargetRegisterClass *A, const TargetRegisterClass *B, const MVT::SimpleValueType SVT...

...e would still behave the same as the original. At the same time, any subsequent optimization may "exploit" the incorrect liveness information to do something bad. If you add -run-pass if-converter, you'll get: # After If Converter # Machine code for function fred: IsSSA, NoPHIs, TracksLiveness, NoVRegs BB#0: %R0<def> = L2_ploadruhf_io %P0<undef>, %R0<undef>, 0, %R0<imp-use> PS_storerhabs 0, %R0 PS_jmpret %R31<kill>, %PC<imp-def> # End machine code for function fred. *** Bad machine code: Using an undefined physical re...

Hi, I'd like to understand how register allocation works in the case where an instruction is folded into another one. Where in the code would be a good place to start looking at? After ISEL, one of the instructions has another instruction folded into it, which looks like this t1: i32,i1,i1,i1,i1 = ADDRR TargetFrameIndex:i32<0>, MOVRI:i32,i1,i1 But during the 'Assembly

...r goes to the side block (BB#1), or > to the join block (BB#2). The register R0 is defined in BB#0 and then > redefined in BB#1. Both definitions can reach the use of R0 in BB#2: > > > *** > Before Hexagon RDF optimizations > # Machine code for function fred: IsSSA, NoPHIs, TracksLiveness, NoVRegs > > BB#0: >     Live Ins: %P0 >         %R0<def> = IMPLICIT_DEF >         J2_jumpt %P0, <BB#2>, %PC<imp-def>  ; Conditional branch to BB#2 >     Successors according to CFG: BB#1 BB#2 > > BB#1: >     Predecessors according to CFG: BB...

...e same as the original. At the same time, any subsequent optimization may "exploit" the incorrect liveness information to do something bad. If you add -run-pass if-converter, you'll get: >> >> # After If Converter >> # Machine code for function fred: IsSSA, NoPHIs, TracksLiveness, NoVRegs >> >> BB#0: >> %R0<def> = L2_ploadruhf_io %P0<undef>, %R0<undef>, 0, %R0<imp-use> >> PS_storerhabs 0, %R0 >> PS_jmpret %R31<kill>, %PC<imp-def> >> >> # End machine code for function f...

Hi Venu, > On Sep 11, 2017, at 11:00 PM, Raghavan, Venugopal via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Krzysztof, > > Thanks for your reply. > > I agree that adding extra register units for x86 would be the right way to fix this. Do you know if there is a plan to fix this? No concrete plan, no. We've been thinking about for quite some time now, but

...r goes to the side block > (BB#1), or to the join block (BB#2). The register R0 is defined in > BB#0 and then redefined in BB#1. Both definitions can reach the use of R0 in BB#2: > > > *** > Before Hexagon RDF optimizations > # Machine code for function fred: IsSSA, NoPHIs, TracksLiveness, > NoVRegs > > BB#0: >     Live Ins: %P0 >         %R0<def> = IMPLICIT_DEF >         J2_jumpt %P0, <BB#2>, %PC<imp-def>  ; Conditional branch to > BB#2 >     Successors according to CFG: BB#1 BB#2 > > BB#1: >     Predecessors accordin...

...registers; this could be enforced via an assert or whatever, and it would be clear and obvious (both for new and existing passes) whether a pass should expect to deal with vregs or not. This kind of thing might also be useful for the purposes MachineRegisterInfo::isSSA() and/or MachineRegisterInfo::tracksLiveness() serve as well I've been experimenting with such a mechanism (the details of how it would be implemented could be a separate discussion) with X86 and WebAssembly, and looking at what passes run, what would need to be modified, the effects of disabling them, etc. Currently the following...

...un-pass=machine-scheduler -o - -verify-misched foo.mir # Before machine scheduling. ********** INTERVALS ********** %0 [16r,16d:1)[32r,32d:0) 0 at 32r 1 at 16r weight:0.000000e+00 RegMasks: ********** MACHINEINSTRS ********** # Machine code for function multiple_connected_components_dead: NoPHIs, TracksLiveness 0B bb.0: 16B dead %0:vgpr_32 = V_MOV_B32_e32 0, implicit $exec 32B dead %0:vgpr_32 = V_MOV_B32_e32 1, implicit $exec # End machine code for function multiple_connected_components_dead. *** Bad machine code: Multiple connected components in live interval *** - fun...

On Tue, 18 Dec 2018 at 07:11, Gleb Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > However, I haven't managed to get a "Constant<>" in the DAG when compiling for X86. I'm interested in how it is lowered. Can you please give me some guidance on this? How are you looking? When I run "llc -mtriple=x86_64-linux-gnu -debug-only=isel" on your IR I get

The comment in test/CodeGen/X86/branchfolding-undef.mir states that such merging is legal, however doing so can actually generate wrong code: Consider this (valid code): --- name: fred tracksRegLiveness: true body: | bb.0: successors: %bb.1, %bb.2 J2_jumpt undef %p0, %bb.2, implicit-def %pc J2_jump %bb.1, implicit-def %pc bb.1: successors: %bb.3 %r0 =

Hello, Consider this code (this is all after register allocation): R0<def> = ... R0 // Set lower half (based on the previous value) R1<def> = ... // Set upper half ... = R0_R1 // Use the pair It is my understanding that the use of the whole pair will need to have some sort of a reaching def, i.e. the code will need at least those flags: R0<def> =

...the join block (BB#2). The register R0 is defined in > BB#0 and then redefined in BB#1. Both definitions can reach the > use of R0 in BB#2: > > > *** > Before Hexagon RDF optimizations > # Machine code for function fred: IsSSA, NoPHIs, TracksLiveness, > NoVRegs > > BB#0: >       Live Ins: %P0 >           %R0<def> = IMPLICIT_DEF >           J2_jumpt %P0, <BB#2>, %PC<imp-def>  ; Conditional > branch to > BB#2 >       Successors a...

...d be enforced via an assert or whatever, and it would > be clear and obvious (both for new and existing passes) whether a pass > should expect to deal with vregs or not. This kind of thing might also be > useful for the purposes MachineRegisterInfo::isSSA() and/or > MachineRegisterInfo::tracksLiveness() serve as well > > I've been experimenting with such a mechanism (the details of how it would > be implemented could be a separate discussion) with X86 and WebAssembly, > and looking at what passes run, what would need to be modified, the effects > of disabling them, etc. &...

...>>> BB#0 and then redefined in BB#1. Both definitions can reach the >>> use of R0 in BB#2: >>> >>> >>> *** >>> Before Hexagon RDF optimizations >>> # Machine code for function fred: IsSSA, NoPHIs, TracksLiveness, >>> NoVRegs >>> >>> BB#0: >>> Live Ins: %P0 >>> %R0<def> = IMPLICIT_DEF >>> J2_jumpt %P0, <BB#2>, %PC<imp-def> ; Conditional >>> branc...

Hi, On SystemZ there are a set of "access registers" that can be copied in and out of 32-bit GPRs with special instructions. These instructions can only perform the copy using low 32-bit parts of the 64-bit GPRs. As reported and discussed at https://bugs.llvm.org/show_bug.cgi?id=44254, this is currently broken due to the fact that the default register class for 32-bit integers is

...0 [48r,288r:0) 0 at 48r weight:0.000000e+00 %1 [32r,304r:0) 0 at 32r weight:0.000000e+00 %2 [16r,320r:0) 0 at 16r weight:0.000000e+00 %3 [80r,336r:0) 0 at 80r weight:0.000000e+00 RegMasks: 144r 240r 336r ********** MACHINEINSTRS ********** # Machine code for function uECC_shared_secret: NoPHIs, TracksLiveness Constant Pool: cp#0: @foo, align=4 Function Live Ins: $r0 in %0, $r1 in %1, $r2 in %2 0B bb.0.entry: liveins: $r0, $r1, $r2 16B %2:tgpr = COPY $r2 32B %1:tgpr = COPY $r1 48B %0:tgpr = COPY $r0 64B ADJCALLSTACKDOWN 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 80B %3:tgp...

Well, that's the thing: I thought that was CopyToReg. I don't know what the name of the node is to load one value into a register, so I don't know how to construct such a pattern. On Sat, Nov 4, 2017 at 9:23 PM Craig Topper <craig.topper at gmail.com> wrote: > Do you have a pattern for loading an i16 immediate into a 16-bit register? > > ~Craig > > On Sat, Nov 4,

If I'm understanding what's going on in this test correctly, what's happening is: * ARMTargetLowering::LowerCall prefers indirect calls when a function is called at least 3 times in minsize * In thumb 1 (without -fno-omit-frame-pointer) we have effectively only 3 callee-saved registers (r4-r6) * The function has three arguments, so those three plus the register we need to hold the