search for: novregs

Maybe MF.getProperties().hasProperty(MachineFunctionProperties::Property::NoVRegs))? ~Craig On Mon, Jan 15, 2018 at 12:07 PM, Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi LLVM Devs, > > > > I have some shared code that performs lowering operations that can occur > before or after register allocation. When it is pre-RA...

Hi LLVM Devs, I have some shared code that performs lowering operations that can occur before or after register allocation. When it is pre-RA I want to only use virtual registers for intermediate results, but post-RA I have to use only a very restricted set of physical registers. Code generation using the restricted set is not as efficient as it is when I can use virtual registers. At

...have 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 register *** - f...

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

...re are no vregs used, when loading a .mir file for example the flag is computed from scratch and will be set. > On Jan 15, 2018, at 12:26 PM, Craig Topper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Maybe MF.getProperties().hasProperty(MachineFunctionProperties::Property::NoVRegs))? > > ~Craig > > On Mon, Jan 15, 2018 at 12:07 PM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi LLVM Devs, > > > > I have some shared code that performs lowering operations that can oc...

...de 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#0 >      ...

...iginal. 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. >>...

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

...ck > (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#0 >...

...a .mir file for example the flag is computed from scratch and will be set. On Jan 15, 2018, at 12:26 PM, Craig Topper via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote: Maybe MF.getProperties().hasProperty(MachineFunctionProperties::Property::NoVRegs))? ~Craig On Mon, Jan 15, 2018 at 12:07 PM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote: Hi LLVM Devs, I have some shared code that performs lowering operations that can occur before or after register allocati...

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 =

...egister 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...

...defined 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 >...