> On Dec 9, 2014, at 3:45 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >> I guess it's because we disabled the integrated-asm, so it won't complain when compiling the kernel. > > No, it's something different. The inline assembly (for whatever > reason) says to use a "dmb ishst" rather than an "stlr". I don't > actually think the reason is that important, it's just surprising > because I'd expect stlr to be more efficient.I see .... guess I'm using an old version of Linux kernel ... from the Android branch ...> Thanks for the IR snippet (I agree, it does look like the order is > reasonable there), but it's not really enough to debug the problem. We > need an actual Module we can compile and examine to have a hope of > finding out what's going on.You mean the source code I'm compiling? Thanks, Chengyu
>> Thanks for the IR snippet (I agree, it does look like the order is >> reasonable there), but it's not really enough to debug the problem. We >> need an actual Module we can compile and examine to have a hope of >> finding out what's going on. > > You mean the source code I'm compiling?The whole .ll file you pulled those lines from looks like it would be most useful (assuming we're right that the IR is sound). If that fails, we can move further back to the C source in some form or another. Cheers. Tim.
Should I just copy and paste the content of the .ll file? Thanks, Chengyu> On Dec 9, 2014, at 4:35 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >>> Thanks for the IR snippet (I agree, it does look like the order is >>> reasonable there), but it's not really enough to debug the problem. We >>> need an actual Module we can compile and examine to have a hope of >>> finding out what's going on. >> >> You mean the source code I'm compiling? > > The whole .ll file you pulled those lines from looks like it would be > most useful (assuming we're right that the IR is sound). If that > fails, we can move further back to the C source in some form or > another. > > Cheers. > > Tim.