search for: add16mm

...tile i16* @x, align 2, !tbaa !0 > %add = add i16 %1, %0 > store i16 %add, i16* @y, align 2, !tbaa !0 > ret void > } > > has a chain store->load volatile->load. I thought this meant that the load volatile had to occur _after_ the load but the MSP430 backend selects the ADD16mm instruction for which I suspect the order of operand access isn't specified. So, does the chain mean "no earlier than" rather than "later than"? No, a chain is supposed to mean "later than". It sounds like MSP430 is bending the rules here. Dan

> No, a chain is supposed to mean "later than". It sounds like MSP430 is bending > the rules here. The instruction selector for ADD16mm is autogenerated, so, this is not MSP430 bug alone :) This is just the single target in the tree which has mem-mem instructions. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...n 2, !tbaa !0 %1 = load volatile i16* @x, align 2, !tbaa !0 %add = add i16 %1, %0 store i16 %add, i16* @y, align 2, !tbaa !0 ret void } has a chain store->load volatile->load. I thought this meant that the load volatile had to occur _after_ the load but the MSP430 backend selects the ADD16mm instruction for which I suspect the order of operand access isn't specified. So, does the chain mean "no earlier than" rather than "later than"? On 14 Aug 2012, at 16:43, Steve Montgomery wrote: > I looked into those patches but I don't think they will help in my s...

I looked into those patches but I don't think they will help in my situation because my problems occur during instruction selection rather than scheduling. A simple and concrete example is a pattern like: [(set GR:$dst (add GR:$src (nvload addr:$mem)))] where nvload matches a load provided that isVolatile() is false. If the selection DAG looks like: | | LD1 LD2 ^