similar to: bugpoint seems to generate a broken Module

We have run an experiment in which we set all physical register limits to zero. The purpose of this experiment was estimating the potential impact of getting complete liveness info. The results of this experiment were better than the results that we got using the real physical limits (the total number of spills in CPU2006 was reduced), but the difference was not substantial. We took this as an

"Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org> writes: > One concern that I have is that, from personal experience, the ability > for bugpoint to reduce the set of optimization passes applied in order > to reproduce a bug is extremely helpful. I understand your desire to > decouple the logic somewhat, and maybe there's some way to generalize > that

On 6/11/19 12:25 PM, Philip Reames via llvm-dev wrote: At the moment, bugpoint has three major use cases: crash reduction, miscompile reduction, and mutation fuzzing. Out of these, a huge proportion of the interface complexity comes from the miscompile handling. I generally agree with removing the auto-detection logic. I've found it to be extraordinarily error prone and confusing.

I would expect that it shouldn't be too hard to pass around a reference to LiveIntervalAnalysis*. Patches welcome :) - Matthias > On Apr 27, 2016, at 11:38 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ping. > > Either this can be implemented easily, or the current SystemZ optimization LAY -> AGSI in foldMemoryOperandImpl() should be

Hi Andy, >> Right now it seems that BeginGroup/EndGroup is only used by SystemZ, >> or? I see they are used in checkHazard(), which I actually don't see >> as helpful during pre-RA scheduling for SystemZ. Could this be made >> optional, or perhaps only done post-RA if target does post-RA >> scheduling? SystemZ does post-RA scheduling to manage decoder

Jonas/Renato, >I think it's mostly about the success rate, given it's too conservative. But in the past 2 years, improvements in (and around) the LV have been slowed down a bit due to the move >to VPlan. It wasn't our intention to slow down LV improvements, but if the project ended up causing other developers take the stance of wait-and-see, that's an inevitable side effect

> On May 14, 2018, at 11:10 AM, Jonas Paulsson <paulsson at linux.vnet.ibm.com> wrote: > > Hi Andrew, > > Thank you very much for the most helpful explanations! Many things could go in as comments, if you ask me - for example: > > --- >> The LLVM machine model is an abstract machine. > >> The abstract pipeline is built around the notion of an

Hi Hal, yes, it's all about the induction variable. SystemZ has a late pass (pre-emit) that looks for MI sequences that can be rewritten to 'branch on count'. Currently only about half the number of BRCTs are output compared to gcc on the same benchmarks. One reason for this is that when a loop gets unrolled, the loop gets a greater increment / decrement than 1, which makes the

Hi Jonas, Are you talking specifically about the induction variable? You might look at what I did for PowerPC's counter-based loops (lib/Target/PowerPC/PPCCTRLoops.cpp, etc.). -Hal ----- Original Message ----- > From: "Jonas Paulsson via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, March 28,

Hi, I have been experimenting for a while with tryCandidate() method of the pre-RA mischeduler. I have by chance found some parameters that give quite good results on benchmarks on SystemZ (on average 1% improvement, some improvements of several percent and very little regressions). Basically, I add a "latency heuristic boost" just above processor resources checking:

Hi, I found with the help of the optimization remarks a loop that could not be vectorized, but if loop distribution was enabled this may happen, which it in fact did with a very significant benchmark improvement (~25%). I tried (on SystemZ) to enable this pass, and found that it only affected a handful of files on SPEC. This means I could enable this without worrying about any regressions on

Hi Andrew, Thank you very much for the most helpful explanations! Many things could go in as comments, if you ask me - for example: --- > The LLVM machine model is an abstract machine. > The abstract pipeline is built around the notion of an "issue point". This is merely a reference point for counting machine cycles. > > > IssueWidth is meant to be a hard in-order

Hi, I am looking for a way to rewrite induction variables to use an addition of -1 whenever possible (and not otherwise unprofitable). This is needed to utilize hardware loop instructions, which are present on SystemZ (branch on count). Later in the backend, an 'add -1; compare w/ 0; jne 0'-sequence can be replaced with a brct instruction. I could not find any way in the LSR pass to

Hi, I have come across a major regression resulting after SLP vectorization (+18% on SystemZ, just for enabling SLP). This all relates to one particular very hot loop. Scalar code: %conv252 = zext i16 %110 to i64 %conv254 = zext i16 %111 to i64 %sub255 = sub nsw i64 %conv252, %conv254 ... repeated SLP output: %101 = zext <16 x i16> %100 to <16 x i64> %104 = zext

Hi Jonas, Thanks for bringing that up. > On Nov 30, 2017, at 4:04 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > we are in the midst of an interesting work that begun with setting 'guessInstructionProperties = 0' in the SystemZ backend. We have found this to be useful, and discovered many instructions where the hasSideEffects flag

Hi, I have worked a little on the PBQP register allocator, and it is quite clear (at least to me) that it is not even a serious alternative to RegAllocGreedy at the moment, due to the poor handling of spilling. As Arnaud wrote below, it is not optimizing spilling at all, but rather just spills anything that does not get an assignment. The result is a lot more spill/reload instructions than

Hi Quentin, Jonas, Splitting fits in with PBQP reasonably well, at least conceptually. The PBQP graph is designed to be mutable, so there is no problem with updating it when splitting. As I see it, there are two logical places to integrate splitting into PBQP: 1) Split during spilling -- If a PBQP solution selects the spill option for a node, rather than spill immediately, split the interval

Hi, I wonder if live-in lists can be trusted to be accurate during register allocation / foldMemoryOperandImp(). On SystemZ, a compare register-register which has one of the registers spilled can fold that reload into a compare register-memory instruction. In order to do this also with the first (LHS) register, the operands must be swapped. This can only reasonably be done when all the CC

Hi, It has been discovered recently that it is needed for the SystemZ backend to add super-regs to the callee saved regs list like: def CSR_SystemZ : CalleeSavedRegs<(add (sequence "R%dD", 6, 15), - (sequence "F%dD", 8, 15))>; + [R6Q, R8Q, R10Q, R12Q, R14Q], +

Both approaches are not exclusive. I would even think it makes sense to have a pre-split pass to prepare the graph, with a global view, and later on use use trySplit (or an equivalent) to handle the local coloring issues. From: Quentin Colombet [mailto:qcolombet at apple.com] Sent: 09 March 2015 23:08 To: Lang Hames Cc: Jonas Paulsson; llvmdev at cs.uiuc.edu; Arnaud De Grandmaison Subject: