search for: isssa

Hi, I noticed that a while ago the isSSA flag was removed from MIR, and this property is now computed. However, the deduction only checks the virtual registers (whether they are assigned to more than once). Now I have MIR tests which live after RA, so they only contain physical registers, so the parser determines they are in SSA form....

I see, thanks. I used to work with GCC, which has an SSA-property verification run after each pass. It is surprising to find that LLVM does not check this! Jonas > Subject: Re: [LLVMdev] subregisters, def-kill > From: stoklund at 2pi.dk > Date: Thu, 19 May 2011 15:39:40 -0700 > CC: llvmdev at cs.uiuc.edu > To: jnspaulsson at hotmail.com > > > On May 19, 2011, at 7:47

..., S2, S3, 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::SimpleVal...

...folding the code 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 un...

Assume an architecture that has multiple condition code registers, e.g., powerpc. Now assume that there are predicate instructions like thumb2, but can specify which condition code register they refer to. Now also assume that these predicate instructions themselves are predicatible, if executed they change the current predication state. Can LLVM handle multiple levels of predication? When is

...0), which either 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 a...

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

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

...0), which either 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: >     Pr...

...d declare that they support virtual 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 disabl...

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

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of

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 =

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

...support virtual > 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 modifie...

...gt;>> 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 >&gt...

...wrote: > > > I see, thanks. > > > > I used to work with GCC, which has an SSA-property verification run after > each pass. It is surprising to find that LLVM does not check this! > > It should. Here is how you can fix it: > > - Add a flag to MachineRegisterInfo: isSSA(). It should be true initially > and cleared by the 2-addr and phi-elim passes. > > - Add code to MachineVerifier.cpp that checks for multiple virtual register > defs when MRI->isSSA() is true. > > Then send your patches to llvm-commits! > > Thanks, > > /jakob >...

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

Hello. Does anybody have an idea why I'm getting the error below when using llc with arguments -O1 -disable-cgp? Note that this error is not given when using llc -O0. (I'd like to mention also I'm using custom Instruction selection for BUILD_VECTOR, which gets converted in my back end's machine instrution VLOAD_D, although the custom code seems to always select

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,