similar to: [LLVMdev] Dis-assembler

On Feb 17, 2012, at 7:18 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > Hi, > > I would like to make a disassembler for my target that reads .s files into a MachineFunction with MachineInstrs. Is this possible? > Nope. -eric

Could you please expand a bit? Why are not the MCInstr and MachineInstr classes compatible? Is this not a long term goal, even? Could I make optimization passes in the MC layer with a disassembler as in a MachineFunction? Thanks, Jonas -----Original Message----- From: Eric Christopher [mailto:echristo at apple.com] Sent: Friday, February 17, 2012 8:20 PM To: Jonas Paulsson Cc: LLVMDEV

Hi Jonas, I won’t have time to look at it this week after all. I’ll try to do that next week. If you do not hear back from me by end of next, do not hesitate to ping me! Cheers, -Quentin > On Apr 22, 2015, at 9:32 AM, Quentin Colombet <qcolombet at apple.com> wrote: > >> >> On Apr 21, 2015, at 11:49 PM, Jonas Paulsson <jonas.paulsson at ericsson.com

I looked at SplitKit, but I am not sure how to best do it, so it would be great if you could take a look. /Jonas On 2015-04-21 19:35, Quentin Colombet wrote: >> On Apr 21, 2015, at 7:40 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> >> >>> On Apr 21, 2015, at 05:39, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: >>> >>>

Hi, I would be happy to give it a try :-) The fact that AA was added at a later point explains the situation a bit, as much fewer SUs should end up in RejectMemNodes without it. RejectMemNodes is bad in that it mixes all the SUs together again, after having gone through the work of separating them by analyzing their underlying objects. It is also very confusing to have two "stages" of

Hi Jonas, When is the MachineVerifier complaining? I mean after which pass? Thanks, -Quentin > On Apr 17, 2015, at 7:17 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > > Hi, > > thanks for answering, but the COPY is there already from after isel. It is a copy of a subreg, after a a call returning 64 bits. > > call

Hi Jonas, > On Apr 20, 2015, at 4:03 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > > Hi Quentin, > > After Simple Register Coalescing. Is the code you have pasted with the PHIs feed to the register coalescer? I am trying to understand the setting to help debugging the problem. Also, what does -debug-only=regalloc tell you? Thanks, -Quentin > >

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

On Apr 17, 2013, at 2:33 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, April 17, 2013 12:22:49 AM >> Subject: RE: [LLVMdev] alias analysis in backend

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 am trying to add Hazard scheduling nodes after buildSchedGraph(), with a scheduler derived from ScheduleDAGInstrs. I get weird errors, so I wonder what I am doing wrong? What I am doing right now is: I have a created MI with opcode HAZARD that does not have parent, and I greate a SUnit(HazardMI). I use this one HazardMI for all hazard nodes. I remove all edges using removePred. I insert

Hi Hal, Thanks. How about a symbol with two different immediate offsets - the Value* would be the same, right? I don't see how AliasAnalysis::Location would handle this... And BasicAliasAnalysis does if (V1 == V2) return MustAlias; , so I'm not sure how this would be done .. ? /Jonas > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent:

Hi, Recently on trunk, the ovlaps list for a register got a dual entry on my target, which caused the RA to crash. Reg Subreg1 Subreg b Subreg2 Subreg b I have a register with two subregs that have subreg b in common. This causes the SuperReg to appear twice in the ovelaps list for Subreg b. As this causes a register allocator to crasch (it evicts a register, and then inremenets

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:

Hi Quentin, I have rerun the test case on a recent commit, so the numbers have changed. There are also now a few more basic blocks very small basic blocks in the function, and therefore there are some slight differences. I tried to go back to earlier commits, without success for some reason... This is however very similar, except that there becomes two COPYs back to sibling value after the loop.

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

Hi Jonas, Thanks for your patience. After spending some time looking at the additional output you gave me, I agree that your fix is the right one. I was worried that this problem may arise because we were spilling not real user, but in fact what I thought was the problem is an optimization we could do :). See my comments inlined for a few nitpicks before you commit. Thanks again, -Quentin On

On Sep 5, 2014, at 10:21 AM, Juergen Ributzka <juergen at apple.com> wrote: > clearKillFlags seems a little "overkill" to me. In this case you could just simply transfer the value of the kill flag from the SrcReg to the DstReg. We are extending the live-range of SrcReg. I do not see how you could relate that to the kill flag of DstReg. Therefore, I still think, this is the

Hi Quentin, I have tried to find a test case for an official target, but failed. It seems to be a rare case. To do it, I added the 'else' clause in the following: ... if (VNI->def == OrigVNI->def) { DEBUG(dbgs() << "orig phi value\n"); SVI->second.DefByOrigPHI = true; SVI->second.AllDefsAreReloads = false; propagateSiblingValue(SVI); continue;

Hi Jonas, Could you file a PR with your test case please? Thanks, -Quentin > On Apr 16, 2015, at 3:50 PM, Andrew Trick <atrick at apple.com> wrote: > >> >> On Apr 16, 2015, at 6:58 AM, Jonas Paulsson <jonas.paulsson at ericsson.com <mailto:jonas.paulsson at ericsson.com>> wrote: >> >> Hi, >> >> I have come across a csmith generated