search for: svoperand

Hi, > * There are still a variety of places in SelectionDAG creation that > don't preserve SVOperand/SVOffset (as well as alignment and > volatile). > > These places need to be found and fixed. This is pretty straight- > forward, > and the places that need changing can be found by inserting some > strategic assert(SVOperand)'s. I've seen at least one place that passe...

...site problem; it understands integer arithmetic and PHIs quite well, but doesn't currently understand GEPs. I know it can be made to understand GEPs though, and it's on my TODO list to implement this. * There are still a variety of places in SelectionDAG creation that don't preserve SVOperand/SVOffset (as well as alignment and volatile). These places need to be found and fixed. This is pretty straight- forward, and the places that need changing can be found by inserting some strategic assert(SVOperand)'s. * The DAGCombiner's alias-analysis handling isn't ideal. This...

...is is obviously not always the case, but it is VERY VERY VERY often the case, so we should see how far that gets us. If nothing else, it makes the IR sent into the codegen simpler and smaller. > * There are still a variety of places in SelectionDAG creation that > don't preserve SVOperand/SVOffset (as well as alignment and > volatile). > > These places need to be found and fixed. This is pretty straight- > forward, > and the places that need changing can be found by inserting some > strategic assert(SVOperand)'s. This is also a serious issue that can manifest...

Dan Gohman wrote: > I tried out your patch on x86 and it didn't appear to need any special changes. it might be needed to look at the addressing modes of a load/store to get the right offset. but i think it should work, if the lowering does not rewrite loads/stores into custom DAG nodes. > For the [??], it looks like the IsFrameIndex isn't getting set for the first > instruction