search for: insert_leaf_info

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 o...

...g uninitialized address f90006b3 str x19, [x21,#8] > Do you have preprocessed source or LLVM IR handy? (You can get a .i > file from "clang -save-temps" for example). The IR looks OK to me, the order is correct. I think the optimization is on machine code. The code is part of the insert_leaf_info function in net/ipv4/fib_trie.c %37 = getelementptr inbounds %struct.leaf_info* %new, i64 0, i32 0, !dbg !10245 %38 = getelementptr inbounds %struct.leaf_info* %li.0.lcssa, i64 0, i32 0, !dbg !10245 tail call void @llvm.dbg.value(metadata !{%struct.hlist_node* %37}, i64 0, metadata !10246, m...

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

Hi, I got an optimization problem (O1, O2) regarding memory barrier “dmb ishld” I find in the test/CodeGen/AArch64/intrinsics-memory-barrier.ll , it’s stated that memory access around DMB should not be reordered, but when compiling the Linux kernel, I found load/store in static inline void hlist_add_before_rcu(struct hlist_node *n, struct hlist_node *next) { n->pprev