search for: csong84

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

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

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

On Mon, Dec 08, 2014 at 11:46:45AM -0800, David Majnemer wrote: > I'm pretty sure this is fixed in r223684. This particular use of > zero-sized arrays should defeat any chance of compile-time address equality. I object that change. It's a horrible special case hack for either a fundamental issue in the IR or plain UB on the source level. As such, it should be reverted. Joerg

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

> It's difficult to say without a full example, but I'm very suspicious > of those global declarations. I think the compiler would be entirely > justified in assuming you could *never* get from __start_builtin_fw to > __end_builtin_fw, let alone on the first iteration: they're distinct > array objects and by definition (within C99) can't overlap. I think this should

I was trying to build the Linux kernel with clang and observed a crash due to incorrect loop optimization: drivers/base/firmware_class.c extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; static bool fw_get_builtin_firmware(struct firmware *fw, const char *name) { struct builtin_fw *b_fw; for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw;

> 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

>> 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"

Hi Tim, > That barrier should be treated the same as any other dmb by LLVM. What > I'm most confused about is why it's there in the first place. From > what I can tell, the rcu_assign_pointer function should map to a > native store-release operation (stlr). I guess it's because we disabled the integrated-asm, so it won't complain when compiling the kernel. > Also,