>> Switching to a clean built on r223853, it still gives me: >> >> ldr x8, [x21,#8] >> stp x21, x8, [x19] >> dmb ishst >> ldr x8, [x19,#8] >> str x19, [x8] >> str x19, [x21,#8] > > Isn't that correct though? The problematic "str" has been folded into > the "stp" instruction, so "x19 + 8" is written before it gets read.Indeed. I didn't pay too much attention to the str -> stp change. Unfortunately, the trunk build crashes when compiling the kernel. Hope it will be fixed tomorrow, else I need to find a revision that gives me this fix. Thank you so much! Chengyu
> Indeed. I didn't pay too much attention to the str -> stp change.Oh good. I can reproduce it now, on the build you were using. Still only with Clang rather than llc, but that's just a minor inconvenience. It should still be solvable.> Unfortunately, the trunk build crashes when compiling the kernel. Hope it will be fixed tomorrow, else I need to find a revision that gives me this fix.Ah, that's not so good. Still, probably better than the silently wrong code you had to debug. Cheers. Tim.
On 9 December 2014 at 16:29, Tim Northover <t.p.northover at gmail.com> wrote:>> Indeed. I didn't pay too much attention to the str -> stp change. > > Oh good. I can reproduce it now, on the build you were using. Still > only with Clang rather than llc, but that's just a minor > inconvenience. It should still be solvable.I think this was an intentional fix, rather than just some random change concealing the issue (the improvement bisected down to Tom's r223717, which fits both by description and location). So I think we can probably stop worrying about this one. Cheers. Tim.