search for: atomicexpandpass

...he layout algorithm, and I noted that test/CodeGen/ARM/cmpxchg-weak.ll was affected. Normally, that would be fine, but I noted that the layout changed the fallthrough from the success case to the failure case. I was surprised to see that the success case isn't annotated with a branch weight by AtomicExpandPass.cpp Would it make sense to annotate the success case as more likely when we expand the intrinsic to help guarantee that the success case remains the fallthrough? Even a 2:1 or 3:2 weighting would correct the layout issue I noted. Thanks, Kyle. -------------- next part -------------- An HTML attac...

...algorithm, and I noted that test/CodeGen/ARM/cmpxchg-weak.ll was affected. > > Normally, that would be fine, but I noted that the layout changed the fallthrough from the success case to the failure case. I was surprised to see that the success case isn't annotated with a branch weight by AtomicExpandPass.cpp > > Would it make sense to annotate the success case as more likely when we expand the intrinsic to help guarantee that the success case remains the fallthrough? Even a 2:1 or 3:2 weighting would correct the layout issue I noted. > > Thanks, > Kyle. > _______________________...

...gt; test/CodeGen/ARM/cmpxchg-weak.ll was affected. > > > > Normally, that would be fine, but I noted that the layout changed the > fallthrough from the success case to the failure case. I was surprised to > see that the success case isn't annotated with a branch weight by > AtomicExpandPass.cpp > > > > Would it make sense to annotate the success case as more likely when we > expand the intrinsic to help guarantee that the success case remains the > fallthrough? Even a 2:1 or 3:2 weighting would correct the layout issue I > noted. > > > > Thanks, > &...

...ordering constraints. 8 and 16-bit atomic load/store are therefore supported using 8 and 16-bit load/store plus appropriate fences. See Table A.6 on page 187 in the linked specification for a mapping from C/C++ atomic constructs to RISC-V instructions. ## Background: Lowering atomics in LLVM The AtomicExpandPass can help you support atomics for your taraget in a number of ways. e.g. inserting fences around atomic loads/stores, or converting an atomicrmw/cmpxchg to a LL/SC loop. It operates as an IR-level pass, meaning the latter ability is problematic - there is no way to guarantee that the invariants for...

> From my reading of Atomics.rst, it would be sound to reorder (It does not > say much about load-linked, so I am treating it as a normal load here) > >> store seq_cst >> fence release >> load-linked monotonic > > into > >> load-linked monotonic >> store seq_cst >> fence release > Which would make an execution ending in %old_x = %old_y = 0

...around type canonicalization of loads in various passes 3) Removing complexity from language frontends which need to support atomic operations on floating point types. My initial implementation plan will not require any changes from the backends. I plan to add a lowering step to the existing AtomicExpandPass which will convert atomic operations on floats and vectors to their equivalently sized integer counterparts. Over time, individual backends will be able to opt in - via a TTI hook - to have the new types of atomics handled by the normal isel machinery. I've prototyped this approach with th...

...;, "atomicrmw", and "cmpxchg" instructions that aren't supported by the target, emit libcalls to the new __atomic_* functions, (rather than the current behavior of calling the legacy __sync_* functions.) Additionally, I'd like to move the decision to emit a libcall into AtomicExpandPass, and remove the ability to use Expand in ISel to create a libcall for ISD::ATOMIC_*. Putting the decision there allows querying the target, up front, for its supported sizes, before any other lowering decisions (either other parts of AtomicExpandPass and in ISel). When choosing whether to inline or...

Currently the AtomicExpandPass will lower the following IR: define i1 @foo(i32* %obj, i32 %old, i32 %new) { entry: %v0 = cmpxchg weak volatile i32* %obj, i32 %old, i32 %new _*release acquire*_ %v1 = extractvalue { i32, i1 } %v0, 1 ret i1 %v1 } to the equivalent of the following on AArch64: _*ldxr w8, [x0]*_...

...nd "cmpxchg" instructions that aren't supported by the target, emit > libcalls to the new __atomic_* functions, (rather than the current > behavior of calling the legacy __sync_* functions.) > > Additionally, I'd like to move the decision to emit a libcall into > AtomicExpandPass, and remove the ability to use Expand in ISel to > create a libcall for ISD::ATOMIC_*. Putting the decision there allows > querying the target, up front, for its supported sizes, before any > other lowering decisions (either other parts of AtomicExpandPass and > in ISel). When choos...

...egular accesses, which means that regular loads cannot move "down" a non-temporal barrier, and regular stores cannot move "up" a non-temporal barrier. *Why not just have the compiler add the fences?* LLVM could do this, either as a per-backend thing or a hookable pass such as AtomicExpandPass. It seems more natural to ask the programmer to express intent, just as is done with atomics. In fact, a backend is current free to ignore !nontemporal on load and store and could therefore generate only half of what's requested, leading to incorrect code. That would of course be silly, backend...

On 12/11/2015 01:29 PM, James Y Knight wrote: > > On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> One open question I don't know the answer to: Are there any >> special semantics required from floating point stores which >> aren't met

..."down" a non-temporal barrier, > > and regular stores cannot move "up" a non-temporal barrier. > > > Why not just have the compiler add the fences? > > > LLVM could do this, either as a per-backend thing or a hookable > > pass > > such as AtomicExpandPass . It seems more natural to ask the > > programmer to express intent, just as is done with atomics. In > > fact, > > a backend is current free to ignore !nontemporal on load and store > > and could therefore generate only half of what's requested, leading > > to inc...

Hi, I would like your opinions on the contract we have between the LLVM IR and the backends. * Context * Right now, the backends are supposed to be able to perform instruction selection on any valid LLVM IR. Although this is *not* something I want to change for GlobalISel, I thought I brought that up on the mailing list to discuss the implications. In particular, in the past, some people

...quot;cmpxchg" instructions that aren't supported by the > target, emit libcalls to the new __atomic_* functions, (rather than > the current behavior of calling the legacy __sync_* functions.) > > > Additionally, I'd like to move the decision to emit a libcall into > AtomicExpandPass, and remove the ability to use Expand in ISel to > create a libcall for ISD::ATOMIC_*. Putting the decision there > allows querying the target, up front, for its supported sizes, > before any other lowering decisions (either other parts of > AtomicExpandPass and in ISel). When choosing...

On Thu, Jan 28, 2016 at 08:32:31AM -0800, Reid Kleckner via llvm-dev wrote: > I think Clang should continue to duplicate this information, the same way > we duplicate target datalayout strings. Other than that, sure, we can let > LLVM expand IR operations to libcalls. I don't immediately see a problem > with that. Note that a libcall doesn't necessarily mean using locks. With

...org/gmane.comp.compilers.clang.devel/39084). All executables are statically linked with musl and compiler-rt. ## LLVM commits * Segmented stacks support for the x32 ABI has been fixed. [r218427](http://reviews.llvm.org/rL218427). * Robin Morisset's work on optimisation of atomics continues. AtomicExpandPass now inserts fences itself rather than SelectionDAGBuilder. [r218329](http://reviews.llvm.org/rL218329). * LLVM's libSupport gained a type-safe alternative to `llvm::format()`. [r218463](http://reviews.llvm.org/rL218463). * llvm-vtabledump learned how to dump RTTI structures for the MS ABI. [r...

On 14 June 2018 at 10:28, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> * I'd like to see ARM+AArch64+Hexagon move away from the problematic >> expansion in IR and to have that code deleted from AtomicExpandPass. Are >> there any objections? > > I think it would be a great shame and I'd like to avoid it if at all > possible, though I'm also uncomfortable with the current situation. Thanks for the reply Tim. It's definitely fair to highlight that ARM and AArch64 has few documen...

...gt; support atomic operations on floating point types. > > > This may become relevant for C++, see http://wg21.link/p0020r0 > > > My initial implementation plan will not require any changes from > the backends. I plan to add a lowering step to the existing > AtomicExpandPass which will convert atomic operations on floats > and vectors to their equivalently sized integer counterparts. > Over time, individual backends will be able to opt in - via a TTI > hook - to have the new types of atomics handled by the normal isel > machinery. > >...

Greetings everyone, I am working on Aarch64 LSE out-of-line atomics support in LLVM, porting this GCC series: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01034.html After local design experiments I've got some questions about upstream-suitable ways of implementation. More specifically: 1. Pass to expand atomics to library helper functions calls. These helpers test for the presence

...t; "down" a non-temporal barrier, and regular stores cannot move "up" a > non-temporal barrier. > > > > > > *Why not just have the compiler add the fences?* > > > > LLVM could do this, either as a per-backend thing or a hookable pass such > as AtomicExpandPass. It seems more natural to ask the programmer to > express intent, just as is done with atomics. In fact, a backend is current > free to ignore !nontemporal on load and store and could therefore > generate only half of what's requested, leading to incorrect code. That > would of cour...