On Feb 8, 2013, at 4:03 PM, Cameron Zwarich <zwarich at apple.com> wrote:> How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that for StrongPhiElimination (RIP).Any help would be appreciated. I did a bit of the easy stuff in 2-addr, it has a LIS = getAnalysisIfAvailable<LiveIntervals>() member that it sometimes updates. It has a lot of weird transformations, though. I haven't touched phi-elim yet because of the 'bubble-up' approach. If you want to help with phi-elim, you could hack -early-live-intervals to insert LiveIntervals before phi-elim, and then run MF.verify(this) at the end of runOnMachineFunction(). That should be enough to check that phi-elim updates live intervals correctly even when 2-addr is going to break it later.> IIRC you run into a lot of problems with NEON subregister defs, which might be fixed by your new direct LiveIntervals implementation.The direct live intervals work on anything that has virtual registers - it can handle all the sub-register fun. I don't think you will see any problems with sub-registers in phi-elim because PHI instructions never have sub-register operands. (And this version of phi-elim just inserts a million copies). /jakob
On Feb 8, 2013, at 4:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:> If you want to help with phi-elim, you could hack -early-live-intervals to insert LiveIntervals before phi-elim, and then run MF.verify(this) at the end of runOnMachineFunction(). That should be enough to check that phi-elim updates live intervals correctly even when 2-addr is going to break it later.That reminds me: LiveRangeCalc::extendToUses() has code to deal with PHI instructions, but I am not sure it has ever actually met one. There could be lurking bugs. /jakob
On Feb 8, 2013, at 4:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:> On Feb 8, 2013, at 4:03 PM, Cameron Zwarich <zwarich at apple.com> wrote: > >> How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that for StrongPhiElimination (RIP). > > Any help would be appreciated. > > I did a bit of the easy stuff in 2-addr, it has a LIS = getAnalysisIfAvailable<LiveIntervals>() member that it sometimes updates. It has a lot of weird transformations, though. > > I haven't touched phi-elim yet because of the 'bubble-up' approach. > > If you want to help with phi-elim, you could hack -early-live-intervals to insert LiveIntervals before phi-elim, and then run MF.verify(this) at the end of runOnMachineFunction(). That should be enough to check that phi-elim updates live intervals correctly even when 2-addr is going to break it later.I'll try doing that. Did you ever add a way to update LiveIntervals quickly after splitting an edge or will that have to finally be added? I can skip the critical edge splitting for now.>> IIRC you run into a lot of problems with NEON subregister defs, which might be fixed by your new direct LiveIntervals implementation. > > The direct live intervals work on anything that has virtual registers - it can handle all the sub-register fun. > > I don't think you will see any problems with sub-registers in phi-elim because PHI instructions never have sub-register operands. (And this version of phi-elim just inserts a million copies).Jogging my memory some more, the problem wasn't with values in phis, it was just that the change in pass ordering broke subregister liveness in some other ways. StrongPhiElimination goes after the 2-address pass rather than before it, but it looks like you are preserving the existing ordering. Cameron
On Feb 8, 2013, at 4:37 PM, Cameron Zwarich <zwarich at apple.com> wrote:> On Feb 8, 2013, at 4:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> On Feb 8, 2013, at 4:03 PM, Cameron Zwarich <zwarich at apple.com> wrote: >> >>> How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that for StrongPhiElimination (RIP). >> >> Any help would be appreciated. >> >> I did a bit of the easy stuff in 2-addr, it has a LIS = getAnalysisIfAvailable<LiveIntervals>() member that it sometimes updates. It has a lot of weird transformations, though. >> >> I haven't touched phi-elim yet because of the 'bubble-up' approach. >> >> If you want to help with phi-elim, you could hack -early-live-intervals to insert LiveIntervals before phi-elim, and then run MF.verify(this) at the end of runOnMachineFunction(). That should be enough to check that phi-elim updates live intervals correctly even when 2-addr is going to break it later. > > I'll try doing that. Did you ever add a way to update LiveIntervals quickly after splitting an edge or will that have to finally be added? I can skip the critical edge splitting for now.That doesn't exist yet, we'll need that too. My thinking was to keep a list of all global live ranges in LiveIntervals so we at least don't have to go through all the local virtual registers when splitting a critical edge. (That's how LiveVariables is updated now, and it's slow).> IIRC you run into a lot of problems with NEON subregister defs, which might be fixed by your new direct LiveIntervals implementation. >> >> The direct live intervals work on anything that has virtual registers - it can handle all the sub-register fun. >> >> I don't think you will see any problems with sub-registers in phi-elim because PHI instructions never have sub-register operands. (And this version of phi-elim just inserts a million copies). > > Jogging my memory some more, the problem wasn't with values in phis, it was just that the change in pass ordering broke subregister liveness in some other ways. StrongPhiElimination goes after the 2-address pass rather than before it, but it looks like you are preserving the existing ordering.I see. Yes, things get a lot more complicated after 2-addr has removed INSERT_SUBREG and REG_SEQUENCE instructions. Sub-registers everywhere. /jakob