search for: r124587

...mation in question is safe. That > said, IIRC I fixed a bug there recently; are you using trunk? Perfect! I'm using 2.8 for now (am hoping to roll forward to trunk and stay there in a month or two), and 2.8 only had that check for SIGN_EXTEND_INREG, not SRL or others. The bugfix was in r124587. I'm now seeing a similar problem with SimplifyDemandedBits() on a 4-byte-aligned i8 load. LowerLOAD() emits an aligned LD4 followed by an AND with constant 0xFF. SimplifyDemandedBits() sees this and changes it to a zero-extended LD1. Is this the same situation, where a bugfix was made...

...safe.  That >> said, IIRC I fixed a bug there recently; are you using trunk? > > Perfect!  I'm using 2.8 for now (am hoping to roll forward to trunk and stay > there in a month or two), and 2.8 only had that check for SIGN_EXTEND_INREG, > not SRL or others.  The bugfix was in r124587. > > I'm now seeing a similar problem with SimplifyDemandedBits() on a > 4-byte-aligned i8 load.  LowerLOAD() emits an aligned LD4 followed by an AND > with constant 0xFF.  SimplifyDemandedBits() sees this and changes it to a > zero-extended LD1.  Is this the same situation, wher...

On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson <johnso87 at crhc.illinois.edu> wrote: > Hi All, >     I'm writing a backend for a target which only supports 4-byte, > 4-byte-aligned loads and stores.  I custom-lower all {*EXT}LOAD and > STORE nodes in TargetISelLowering.cpp to take advantage of all alignment > information available to the backend, rather than treat each

Hi All, I'm writing a backend for a target which only supports 4-byte, 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and STORE nodes in TargetISelLowering.cpp to take advantage of all alignment information available to the backend, rather than treat each load and store conservatively, which takes O(10) instructions. My target's allowsUnalignedMemoryOperations()