search for: ishld

> 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

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

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:

>> 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, 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 *nex...

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

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,

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

First off, Apologies for the massive patch series... This series boots a 32-bit dom0 kernel to a command prompt on an ARMv8 (AArch64) model. The kernel is the same one as I am currently using with the 32 bit hypervisor I haven''t yet tried starting a guest or anything super advanced like that ;-). Also there is not real support for 64-bit domains at all, although in one or two places I