search for: addr64

...00000030: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ RELOCATIONS #5 Symbol Symbol Offset Type Applied To Index Name -------- ---------------- ----------------- -------- ------ 00000000 ADDR64 00000000 00000000 0 .text 00000008 ADDR64 00000000 00000000 E call 00000020 ADDR64 00000000 00000056 0 .text 00000028 ADDR64 00000000 00000000 E call SECTION HEADER #6 /4 name (xray_fn_idx) 0 physica...

I'm learning the xray library and try if it can be built on windows, in xray_fdr_logging_impl.h line 152 , comment written as // Using pthread_once(...) to initialize the thread-local data structures but at line 175, 183, code written as thread_local pthread_key_t key; // Ensure that we only actually ever do the pthread initialization once. thread_local bool UNUSED Unused = [] {

...ementptr i32, i32 addrspace(1)* %out, i32 4 > + %0 = cmpxchg volatile i32 addrspace(1)* %gep, i32 %old, i32 %in seq_cst seq_cst > + %1 = extractvalue { i32, i1 } %0, 0 > + store i32 %1, i32 addrspace(1)* %out2 > + ret void > +} > + > +; FUNC-LABEL: {{^}}atomic_cmpxchg_i32_addr64_offset: > +; SI: buffer_atomic_cmpswap v[{{[0-9]+\:[0-9]+}}], v[{{[0-9]+}}:{{[0-9]+}}], s[{{[0-9]+}}:{{[0-9]+}}], 0 addr64 offset:16{{$}} > +define void @atomic_cmpxchg_i32_addr64_offset(i32 addrspace(1)* %out, i32 %in, i64 %index, i32 %old) { > +entry: > + %ptr = getelementptr i32, i3...

Hi Tom, Matt, I'm working on a project that needs few coherent atomic operations (HSA mode: load, store, compare-and-swap) for std::atomic_uint in HCC. the attached patch implements atomic compare and swap for SI+ (untested). I tried to stay within what was available, but there are few issues that I was unsure how to address: 1.) it currently uses v2i32 for both input and output. This

That is basically what we do today to provide mixed sized pointers with our legacy frontends. They generate IR to our old code generator which has ADDR32 and ADDR64 datatypes. We use a 64-bit address data layout and then typecast the 32-bit forms to/from the underlying 64-bit addresses. I have been warned that such rampant typecasting might interfere with certain optimizations or TBAA data. We haven't investigated that yet. Since clang doesn't go t...

...lt;john.reagan at vmssoftware.com <mailto:john.reagan at vmssoftware.com>> wrote: > > That is basically what we do today to provide mixed sized pointers > with > our legacy frontends.  They generate IR to our old code generator > which > has ADDR32 and ADDR64 datatypes.  We use a 64-bit address data layout > and then typecast the 32-bit forms to/from the underlying 64-bit > addresses.  I have been warned that such rampant typecasting might > interfere with certain optimizations or TBAA data.  We haven't > investigated tha...

Can we accept the patch which makes this work? There is a patch in the bug report for the MCJIT case. I'm confused why AOT and MCJIT case would be different but without it the information isn't registered. On Wed, Jul 6, 2016 at 9:07 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > If you want an AOT linker and you don't want to use link.exe, you can use

Please don't bake in knowledge *in LLVM* of a address space unless there's a strong need.  *Clang* can assign whatever meaning to an AS it wishes, and their properties are configurable via data layout configuration. The standards of review are much lower for a Clang only change as it can be revised arbitrarily without breaking other uses of LLVM.  Building in first class knowledge to

...tware.com <mailto:john.reagan at vmssoftware.com>> wrote: >> >> That is basically what we do today to provide mixed sized >> pointers with >> our legacy frontends.  They generate IR to our old code generator >> which >> has ADDR32 and ADDR64 datatypes.  We use a 64-bit address data layout >> and then typecast the 32-bit forms to/from the underlying 64-bit >> addresses.  I have been warned that such rampant typecasting might >> interfere with certain optimizations or TBAA data.  We haven't >>...

...tation, rather than relying on an implementation-specific bus to back this up. - Make virtio_config_ops much higher-level, don't assume layout of config space. - Expose "struct virtqueue" again and move ops inside that. - virtio_ring uses 64 bit address, 32 bit length, not addr64 + offset16 + len16. - flags in virtio_ring to allow suppression of interrupts (by guest) or notifications (by host). I'm not too unhappy with this as it stands. Feedback welcome! Cheers, Rusty.

...tation, rather than relying on an implementation-specific bus to back this up. - Make virtio_config_ops much higher-level, don't assume layout of config space. - Expose "struct virtqueue" again and move ops inside that. - virtio_ring uses 64 bit address, 32 bit length, not addr64 + offset16 + len16. - flags in virtio_ring to allow suppression of interrupts (by guest) or notifications (by host). I'm not too unhappy with this as it stands. Feedback welcome! Cheers, Rusty.

That's encouraging. Assuming that all access to the JITted code is going to be done through a function pointer, and all JIT code is ephemeral, why is the object container format important? In fact, why is it even needed? I found it somewhat odd that MCJIT generates an object file for even the JIT case. To answer my own question, could it be that advanced JIT's may need/want to use things

Hi, This is a proof of concept of GPU forwarding for Linux guest on Linux host. I'd like to get comments and suggestions from community before I put more time on it. To summarize what it is: 1. It's a solution to bring GPU acceleration for Linux vm guest on Linux host. It could works with different GPU although the current proof of concept only works with Intel GPU. 2. The basic idea

Thanks Andy, helpful as always! 1 is a possibility, but not ideal for us. Could you elaborate a little on 3? I don't really know what a jump stub is, but am guessing it's a kind of "alternative symbol" which would just act as a middle man to invoke the "real" symbol in the static library. If that's the case, I can think of a way to implement it for specific