search for: uxtab

...tends to 32 bits, but that's too late to affect the live-out info. MachineCSE and MachineSink do not help because the first zero-extend is folded into the load (LDRB), so the redundant zero-extend (UXTB) does not appear to be a CSE. In another case, the zero-extend is also folded into an add (UXTAB), which prevents the add from being selected to a better alternative (UXTAB does not allow immediate operands). > >> 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 a...

On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote: >> 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're failing to handle. I 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. >

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

...at's too late to affect the live-out info. > > MachineCSE and MachineSink do not help because the first zero-extend is > folded into the load (LDRB), so the redundant zero-extend (UXTB) does not > appear to be a CSE. In another case, the zero-extend is also folded into an > add (UXTAB), which prevents the add from being selected to a better > alternative (UXTAB does not allow immediate operands). > > > > >> 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 wi...