search for: machinesink

Hi Quentin, Jonas looked further into the problem below, and asked me to submit his patch. Note the we have our own out-of-tree target, and we have not been able to reproduce this problem on an in-tree target. /Patrik Hägglund [MachineSinking] Conservatively clear kill flags after coalescing. This solves the problem of having a kill flag inside a loop with a definition of the register prior to the loop: %vreg368<def> ... Inside loop: %vreg520<def> = COPY %vreg368 %vreg568<def,tied1> = add %vreg34...

...> >>> Hi Quentin, >>> >>> Jonas looked further into the problem below, and asked me to submit his patch. Note the we have our own out-of-tree target, and we have not been able to reproduce this problem on an in-tree target. /PatrikHägglund >>> >>> [MachineSinking] Conservatively clear kill flags after coalescing. >>> >>> This solves the problem of having a kill flag inside a loop >>> with a definition of the register prior to the loop: >>> >>> %vreg368<def> ... >>> >>> Inside loop: &...

Hello LLVM-dev, I think I've found an issue with the MachineSink optimization on a program that uses setjmp. It looks like MachineSink will happily move a machine instruction into a following machine basic block (not necessarily a successor), even when that later block can be reached through a setjmp. Here is some example debug output from llc that I'm seei...

...behavior, and the bug went hiding. I then started discussing this onhttps://reviews.llvm.org/D45878, and since this is something that should be handled by all different machine passes, the immediate question is now what utility functions should be made available for common use. 1. A pass such as MachineSink.cpp must first of all remember to consider DBG_VALUEs when iterating over instructions, so that it does not e.g. "break if next instruction is not X" and therefore change its results with -g. 2. At a second priority, a) it should handle DBG_VALUEs when moving / erasing MachineInstrs....

...on and EFLAGS is not marked live-in in successor blocks. How is that different from our case? -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Friday, June 03, 2011 3:53 AM To: Bill Wendling Cc: Galanov, Sergey; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MachineSink and EFLAGS On Jun 2, 2011, at 12:58 PM, Bill Wendling wrote: > On Jun 2, 2011, at 3:53 AM, Galanov, Sergey wrote: > >> Hi Bill. >> >> Thank you very much! Now I see my understanding was incorrect :) A dependence from a single physreg-defining instruction (like CMP or TE...

On Jun 2, 2011, at 3:53 AM, Galanov, Sergey wrote: > Hi Bill. > > Thank you very much! Now I see my understanding was incorrect :) A dependence from a single physreg-defining instruction (like CMP or TEST) is allowed to be shared in several instructions unless that register is not clobbered (and this is what we have with CMOV_FR64). Wouldn't it be safe then to not set the live-in

On Jun 2, 2011, at 12:58 PM, Bill Wendling wrote: > On Jun 2, 2011, at 3:53 AM, Galanov, Sergey wrote: > >> Hi Bill. >> >> Thank you very much! Now I see my understanding was incorrect :) A dependence from a single physreg-defining instruction (like CMP or TEST) is allowed to be shared in several instructions unless that register is not clobbered (and this is what we

...gt; > I then started discussing this on https://reviews.llvm.org/D45878, and > since this is something that should be handled by all different machine > passes, the immediate question is now what utility functions should be > made available for common use. > > 1. A pass such as MachineSink.cpp must first of all remember to consider > DBG_VALUEs when iterating over instructions, so that it does not e.g. > "break if next instruction is not X" and therefore change its results > with -g. We started a similar discussion at the LLVM IR level very recently. As a result o...

...edSelect for instructions which are marked as defining EFLAGS (like the integer pseudo cmovs)? Thanks, Sergey -----Original Message----- From: Bill Wendling [mailto:wendling at apple.com] Sent: Thursday, June 02, 2011 12:00 AM To: Galanov, Sergey Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MachineSink and EFLAGS On Jun 1, 2011, at 9:18 AM, Galanov, Sergey wrote: > Hello. > > I am not sure this is the right place to ask but here is my question. > About a year ago there was a fix of some obscure bug (rdar://problem/8030636 which is located on the internal Apple bugtracker I believ...

On Jun 1, 2011, at 9:18 AM, Galanov, Sergey wrote: > Hello. > > I am not sure this is the right place to ask but here is my question. About a year ago there was a fix of some obscure bug (rdar://problem/8030636 which is located on the internal Apple bugtracker I believe and so not available to the general public J) > Some discussion can be found here:

Thanks for spelling it out, now I understand. On Jun 5, 2011, at 6:11 AM, Galanov, Sergey wrote: > Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. This actually looks like a

...ve-in in the new blocks in EmitLoweredSelect if EFLAGS is a dead def of the pseudo cmov. -----Original Message----- From: Bill Wendling [mailto:wendling at apple.com] Sent: Saturday, June 04, 2011 2:32 AM To: Galanov, Sergey Cc: Jakob Stoklund Olesen; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MachineSink and EFLAGS On Jun 3, 2011, at 2:59 AM, Galanov, Sergey wrote: > Hi, Bill and Jakob. > > I don't quite understand. I am talking about CMOV_GR* instructions which are conservatively marked as clobbering EFLAGS in X86InstrCompiler.td. Doesn't that mean there cannot be any use of EF...

...chineinstrs ...' to get the machine instruction dump.) -bw > -----Original Message----- > From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > Sent: Friday, June 03, 2011 3:53 AM > To: Bill Wendling > Cc: Galanov, Sergey; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] MachineSink and EFLAGS > > > On Jun 2, 2011, at 12:58 PM, Bill Wendling wrote: > >> On Jun 2, 2011, at 3:53 AM, Galanov, Sergey wrote: >> >>> Hi Bill. >>> >>> Thank you very much! Now I see my understanding was incorrect :) A dependence from a single phys...

Hello. I am not sure this is the right place to ask but here is my question. About a year ago there was a fix of some obscure bug (rdar://problem/8030636 which is located on the internal Apple bugtracker I believe and so not available to the general public :)) Some discussion can be found here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100531/102160.html. Unfortunately, no

...avior, and the bug went hiding. I then started discussing this on https://reviews.llvm.org/D45878, and since this is something that should be handled by all different machine passes, the immediate question is now what utility functions should be made available for common use. 1. A pass such as MachineSink.cpp must first of all remember to consider DBG_VALUEs when iterating over instructions, so that it does not e.g. "break if next instruction is not X" and therefore change its results with -g. 2. At a second priority,     a) it should handle DEBUG_VALUEs when moving / erasing Machine...

...rs - MachineFunctionAnalysis - MachineFunction - MachineFunctionPass - MachineFunctionPrinterPass - MachineInstrBundle - MachineInstr - MachineLICM - MachineLoopInfo - MachineModuleInfo - MachineModuleInfoImpls - MachinePassRegistry - MachinePostDominators - MachineRegisterInfo - MachineScheduler - MachineSink - MachineSSAUpdater - MachineTraceMetrics - MachineVerifier Are there any files in this list that should not be moved? Any others that should be added? Any suggestions on which of these modules would be a good place to start? One question of procedure... Back in 2010 and 2011, I had commit rights...

...reserve correctness for stricter models, while more relaxed models can implement additional transforms that use weaker constraints on top of core LLVM. *** HOW *** Once the attribute has been added, we anticipate the following changes to optimization passes will be required: - Restrict Sink and MachineSink for convergent operations - Disabling PRE for convergent operations - Disabling jump threading of convergent operations - Auditing SimplifyCFG for additional transforms that break convergent guarantees *** WHY *** SPMD/SIMT programming models are a family of related programming models in wh...

David, -fsanitize=undefined sounds great, but is not quite what I want. I recently ran into a problem with "CodeGen/MachineSink.cpp” [*], for a target that has to expand Select into control flow. The original IR had two select in a row that were based on the same condition, so the CMP that sets the FLAGS reg in the second select was MCSE’ed to the earlier CMP in the first select, so here we see the second Select without a...

...instruction in early-taildup, and my scripts picked this up as dropping a location. * 2 locations aren't tracked by InstrRefBasedLDV through a block that's out of scope, meaning the location never covers instructions that are in scope. VarLocBasedLDV is vulerable to this too, but MachineSink can drop a DBG_VALUE on the far side of the scope gap, saving the location. See "Limitations" below. * 2 locations dropped during tail duplication: one in early-taildup which I haven't tried to address yet (see "Limitations"), one in late taildup where a block c...

...ubsequent scheduling pass undoes that rescheduling (or some part of it), we will lose or shorten variable locations for no reason. Finally, being forced to always specify both the machine location and the program location at the same time (in a single DBG_VALUE) introduces un-necessary burdens. In MachineSink, when we sink between blocks an instruction that defines a vreg, we chose to sink DBG_VALUE instructions referring to that vreg too to avoid losing the variable location. This un-necessarily risks re-ordering assignments, and in some circumstances [2] you would have to examine all the instructions...