search for: computeliveoutvreginfo

...k at Machine CSE and Machine Sink. Where is the heuristic for tracking live-out vregs that you mention? I'm definitely seeing a reextend of an already extended value. Worse, the value is spilled and the zext is not folded into the reload. The code I'm thinking of is in SelectionDAGISel::ComputeLiveOutVRegInfo > For ARM and possibly other RISC-like targets, you simply can't define an i8 or i16 value -- those aren't legal types. Since those values will always be extended at the point where they are defined, the code placement problem is straightforward: you always want to fold the extends int...

On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > On Aug 18, 2010, at 9:22 AM, Bob Wilson wrote: >> I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. > > That's true, but doing isel as a purely local approach

...ne CSE and Machine Sink. Where is the heuristic for tracking live-out vregs that you mention? I'm definitely seeing a reextend of an already extended value. Worse, the value is spilled and the zext is not folded into the reload. > > The code I'm thinking of is in SelectionDAGISel::ComputeLiveOutVRegInfo For the testcase I'm looking at, ComputeLiveOutVRegInfo does not help because it is called prior to selection when the load is an "any_ext" load. It gets (arbitrarily) selected to LDRB, which zero-extends to 32 bits, but that's too late to affect the live-out info. MachineCSE a...

...Where is the > heuristic for tracking live-out vregs that you mention? I'm definitely > seeing a reextend of an already extended value. Worse, the value is spilled > and the zext is not folded into the reload. > > > > The code I'm thinking of is in SelectionDAGISel::ComputeLiveOutVRegInfo > > For the testcase I'm looking at, ComputeLiveOutVRegInfo does not help > because it is called prior to selection when the load is an "any_ext" load. > It gets (arbitrarily) selected to LDRB, which zero-extends to 32 bits, but > that's too late to affect the live...

----- Original Message ----- > From: "Xinliang David Li" <davidxl at google.com> > To: "Cong Hou" <congh at google.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, November 25, 2015 5:17:58 PM > Subject: Re: [llvm-dev] [RFC] Introducing a vector reduction add