search for: atomicexpand

...is worth, I agree with the usefulness of having a concept of "cleanup pass". Another example of a situation where it would be nice is in the fence elimination patch I sent for review recently: the pass is rather expensive because it relies on several analysis passes, and is only useful if AtomicExpand introduced fences. Being able to say "Only run this pass if the code was modified by this previous pass" would be awesome. Yet another example is the EnableAtomicTidy flag on ARM that runs simplifyCFG after AtomicExpand to cleanup some of the load-linked/store-conditional loops: if no suc...

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]*_...

...th the usefulness of having a concept > of "cleanup pass". Another example of a situation where it would be > nice is in the fence elimination patch I sent for review recently: > the pass is rather expensive because it relies on several analysis > passes, and is only useful if AtomicExpand introduced fences. Being > able to say "Only run this pass if the code was modified by this > previous pass" would be awesome. > Yet another example is the EnableAtomicTidy flag on ARM that runs > simplifyCFG after AtomicExpand to cleanup some of the > load-linked/store-con...

I’ll summarize your responses as: The new pipeline produces better results than the old, and we currently have no good mechanism for reducing the compile time overhead. I’ll summarize my criticism as: In principle, there are better ways to clean up after the vectorizer without turning it into a complicated megapass, but no one has done the engineering. I don’t think cleaning up after the

> 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

...ke meaningful use of the opportunities it provides. I'd like to move it earlier and express it in terms of a first-class pair of "load linked" and "store conditional" instructions. More details are attached and inlined below. Currently the only code I have is for one or two AtomicExpand peepholes, so any suggestions or alternatives would be very welcome. It's possible this is entirely the wrong approach. What do people think? Cheers. Tim. The Problem ----------- We now expand atomic instructions to load-linked & store-conditional intrinsics just before ISel, but this...

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

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