I'm not sure, I was never able to compile the whole kernel with -O0, too many errors. Plus, the problem seems to be within machine code generation. I tried opt -O1 and -O2, the generated .ll file does not diff much for the target function (insert_leaf_info). Thanks, Chengyu> On Dec 9, 2014, at 4:49 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 9 December 2014 at 13:46, Chengyu Song <csong84 at gatech.edu> wrote: >> Then I will attach, and it is compiled with -O0 > > I thought you said the problem occurred at O1 and O2? Does it happen > at O0 as well? We need source that actually produces the problem to > work out what's going on. > > Cheers. > > Tim.
On 9 December 2014 at 13:53, Chengyu Song <csong84 at gatech.edu> wrote:> I'm not sure, I was never able to compile the whole kernel with -O0, too many errors. Plus, the problem seems to be within machine code generation. I tried opt -O1 and -O2, the generated .ll file does not diff much for the target function (insert_leaf_info).I'm not seeing anything resembling the code you originally posted by compiling this (either before or after opt -On). I think it's probably best if we try with preprocessed source. What you need to do is run the clang compile command (the optimised one that fails), but add the "-save-temps" option. It should produce a "fib_trie.i" file in the directory you're running from. Could you upload that and the exact command line you're using? Also, I should have asked earlier, but what version of LLVM are you using? The bug may already have been fixed on trunk. Cheers. Tim.
> Please find it attached. The command I'm using is:Thanks Chengyu. The code is very different from what you started the thread with, and seems correct to me: // x19 == n, x21 == next ldr x8, [x21, #8] stp x21, x8, [x19] stlr x19, [x8] str x19, [x21, #8] Can you confirm that this has the same bug when you try to use it? Cheers. Tim.
On 9 December 2014 at 15:14, Chengyu Song <csong84 at gatech.edu> wrote:> Errr. my fault. I patched the rcu_assign_pointer ... Let me try again.It's looking closer now, but I still can't trigger the bug I'm afraid. Even disabling the load/store optimiser and fiddling with CPUs (to try different schedulers) just gives me what I'd expect: ldr x8, [x21, #8] str x21, [x19] str x8, [x19, #8] dmb ishst ldr x8, [x19, #8] str x19, [x8] I'm not aware of any big changes in this area recently. You don't have any local LLVM patches or anything that could be causing the problem? What revision of trunk did you get it to fail on? I could try checking that one out. Cheers. Tim.
I'm using r223407. 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]
Thanks,
Chengyu
> On Dec 9, 2014, at 6:32 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
>
> On 9 December 2014 at 15:14, Chengyu Song <csong84 at gatech.edu>
wrote:
>> Errr. my fault. I patched the rcu_assign_pointer ... Let me try again.
>
> It's looking closer now, but I still can't trigger the bug I'm
afraid.
> Even disabling the load/store optimiser and fiddling with CPUs (to try
> different schedulers) just gives me what I'd expect:
>
> ldr x8, [x21, #8]
> str x21, [x19]
> str x8, [x19, #8]
> dmb ishst
> ldr x8, [x19, #8]
> str x19, [x8]
>
> I'm not aware of any big changes in this area recently. You don't
have
> any local LLVM patches or anything that could be causing the problem?
> What revision of trunk did you get it to fail on? I could try checking
> that one out.
>
> Cheers.
>
> Tim.