search for: reextend

Hi, When I''m using the Prototype version attached to script.aculo.us 1.6.5 (Prototype 1.5.0_rc1 revision [5462]) I get some "Object doesn''t support this property or method" in the Effect.BlindDown method (when the method tries to get the dimentions). If I''m using the version of prototype that was attached to 1.6.4 I do not get this error. Is this a known

...> > The right answer depends on what and how much you care about this. If you're seeing fully redundant zexts, then I'd look into why machinecse isn't picking this up. If you're seeing partially redundant cases, then machine sink is missing something. If you're seeing reextends of already extended values, then it sounds like the heuristic to track that the live-out vreg is extended isn't working. > > I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use...

...also do think that whole-function selection dags will solve a lot of grossness (e.g. much of codegen prepare) with a very clean model. > > I'll take a look 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...

...hine pass. The right answer depends on what and how much you care about this. If you're seeing fully redundant zexts, then I'd look into why machinecse isn't picking this up. If you're seeing partially redundant cases, then machine sink is missing something. If you're seeing reextends of already extended values, then it sounds like the heuristic to track that the live-out vreg is extended isn't working. I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we...

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. I'm thinking in particular about legalizing integer types that need to be promoted to the target register size, i.e., i8 and i16 for ARM promoting to i32. Currently we sign-extend or

...think that whole-function selection dags will solve a lot of grossness (e.g. much of codegen prepare) with a very clean model. >> >> I'll take a look 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 the testcase I'm looking at, ComputeLiveOutVRegInfo does not help because it is called prior to sele...

...on selection dags will solve a lot of grossness (e.g. much of > codegen prepare) with a very clean model. > >> > >> I'll take a look 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 the testcase I'm looking at, ComputeLiveOutVRegInfo does not help > becaus...