Philip Reames via llvm-dev
2015-Dec-11 02:22 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
Currently, we limit atomic loads and stores to either pointer or integer types. I would like to propose that we extend this to allow both floating point and vector types which meet the other requirements. (i.e. power-of-two multiple of 8 bits, and aligned) This will enable a couple of follow on changes: 1) Teaching the vectorizer how to vectorize unordered atomic loads and stores 2) Removing special casing 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 the x86 backend and get what looks like correct and even fairly efficient instruction selection taking place. I haven't studied it too extensively, so it might not work out in the end, but the approach appears generally feasible. One open question I don't know the answer to: Are there any special semantics required from floating point stores which aren't met by simply bitcasting their result to i32 (float) or i64 (double) and storing the result? In particular, I'm unsure of the semantics around canonicalization here. Are there any? Same for loads? Philip
JF Bastien via llvm-dev
2015-Dec-11 08:05 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
On Fri, Dec 11, 2015 at 3:22 AM, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Currently, we limit atomic loads and stores to either pointer or integer > types. I would like to propose that we extend this to allow both floating > point and vector types which meet the other requirements. (i.e. > power-of-two multiple of 8 bits, and aligned) >I support this. This will enable a couple of follow on changes:> 1) Teaching the vectorizer how to vectorize unordered atomic loads and > stores > 2) Removing special casing around type canonicalization of loads in > various passes > 3) Removing complexity from language frontends which need to 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. > > I've prototyped this approach with the x86 backend and get what looks like > correct and even fairly efficient instruction selection taking place. I > haven't studied it too extensively, so it might not work out in the end, > but the approach appears generally feasible. >Simpler path that D11382 <http://reviews.llvm.org/D11382>, generating the same code? One open question I don't know the answer to: Are there any special> semantics required from floating point stores which aren't met by simply > bitcasting their result to i32 (float) or i64 (double) and storing the > result? In particular, I'm unsure of the semantics around canonicalization > here. Are there any? Same for loads? >I'd go a bit further: should you also support basic FP operations atomically? The above C++ paper adds add/sub, and we've discussed adding FMA as well. This raises similar issues around FP exceptions (are they impl-defined, UB, unspecified? Do we care?). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151211/07fc62a6/attachment.html>
Hal Finkel via llvm-dev
2015-Dec-11 17:20 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
Hi Philip, I think this makes sense. -Hal ----- Original Message -----> From: "Philip Reames via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 10, 2015 8:22:22 PM > Subject: [llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types > > Currently, we limit atomic loads and stores to either pointer or > integer > types. I would like to propose that we extend this to allow both > floating point and vector types which meet the other requirements. > (i.e. power-of-two multiple of 8 bits, and aligned) > > This will enable a couple of follow on changes: > 1) Teaching the vectorizer how to vectorize unordered atomic loads > and > stores > 2) Removing special casing 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 the x86 backend and get what looks > like correct and even fairly efficient instruction selection taking > place. I haven't studied it too extensively, so it might not work > out > in the end, but the approach appears generally feasible. > > One open question I don't know the answer to: Are there any special > semantics required from floating point stores which aren't met by > simply > bitcasting their result to i32 (float) or i64 (double) and storing > the > result? In particular, I'm unsure of the semantics around > canonicalization here. Are there any? Same for loads? > > Philip > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Philip Reames via llvm-dev
2015-Dec-11 20:05 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
On 12/11/2015 12:05 AM, JF Bastien wrote:> On Fri, Dec 11, 2015 at 3:22 AM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Currently, we limit atomic loads and stores to either pointer or > integer types. I would like to propose that we extend this to > allow both floating point and vector types which meet the other > requirements. (i.e. power-of-two multiple of 8 bits, and aligned) > > > I support this.Great. I'll prepare a patch and send it for review.> > > This will enable a couple of follow on changes: > 1) Teaching the vectorizer how to vectorize unordered atomic loads > and stores > 2) Removing special casing around type canonicalization of loads > in various passes > 3) Removing complexity from language frontends which need to > 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. > > I've prototyped this approach with the x86 backend and get what > looks like correct and even fairly efficient instruction selection > taking place. I haven't studied it too extensively, so it might > not work out in the end, but the approach appears generally feasible. > > > Simpler path that D11382 <http://reviews.llvm.org/D11382>, generating > the same code?Actually, I think I was relying on exactly that change. :) My initial implementation just converts "store atomic float 0.0, float* %p unordered, align 4" to %p.i = bitcast float* %p to i32* %v = bitcast float 0.0 to i32 store atomic i32 %v, i32* %p.i unordered, align 4 (i.e. it just does what the frontend previously did in the AtomicExpand.) The net result is that the backend still sees the bitcast idioms you added pattern matching for. Once that parts in, I'll start changing the canonical form the backend expects, but given that's backend specific, I wanted a migration mechanism which worked for all backends. p.s. There's still lots of work to do to improve isel for atomic loads and stores on these types. I plan to eventually get there, but my first focus is on a) functional correctness, and b) getting the middle-end optimizers fixed up.> > > One open question I don't know the answer to: Are there any > special semantics required from floating point stores which aren't > met by simply bitcasting their result to i32 (float) or i64 > (double) and storing the result? In particular, I'm unsure of the > semantics around canonicalization here. Are there any? Same for > loads? > > > I'd go a bit further: should you also support basic FP operations > atomically? The above C++ paper adds add/sub, and we've discussed > adding FMA as well.Just to be clear, I assume you mean extending the atomicrmw, and cmpxchg instructions right? I agree this is worth doing, but I'm purposely separating that into a possible later proposal. I don't need this right now and keeping the work scoped reasonably is key to making progress.> > This raises similar issues around FP exceptions (are they > impl-defined, UB, unspecified? Do we care?).In practice, we seem not to care. This is much broader than my proposal, and I have no opinions on what the right solutions here are. Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151211/f6597d96/attachment.html>
Philip Reames via llvm-dev
2015-Dec-12 00:24 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
Patch posted for review: http://reviews.llvm.org/D15471 Philip On 12/10/2015 06:22 PM, Philip Reames wrote:> Currently, we limit atomic loads and stores to either pointer or > integer types. I would like to propose that we extend this to allow > both floating point and vector types which meet the other > requirements. (i.e. power-of-two multiple of 8 bits, and aligned) > > This will enable a couple of follow on changes: > 1) Teaching the vectorizer how to vectorize unordered atomic loads and > stores > 2) Removing special casing 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 the x86 backend and get what looks > like correct and even fairly efficient instruction selection taking > place. I haven't studied it too extensively, so it might not work out > in the end, but the approach appears generally feasible. > > One open question I don't know the answer to: Are there any special > semantics required from floating point stores which aren't met by > simply bitcasting their result to i32 (float) or i64 (double) and > storing the result? In particular, I'm unsure of the semantics around > canonicalization here. Are there any? Same for loads? > > Philip > > >
JF Bastien via llvm-dev
2015-Dec-12 21:44 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
On Sat, Dec 12, 2015 at 1:24 AM, Philip Reames <listmail at philipreames.com> wrote:> Patch posted for review: http://reviews.llvm.org/D15471Looking at the patch, I think we should do FP only for now as vectors have extra complexities which IMO warrant more discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151212/7a61bdef/attachment.html>
David Chisnall via llvm-dev
2015-Dec-13 21:03 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
Hi Philip,> On 11 Dec 2015, at 02:22, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Currently, we limit atomic loads and stores to either pointer or integer types. I would like to propose that we extend this to allow both floating point and vector types which meet the other requirements. (i.e. power-of-two multiple of 8 bits, and aligned)If you’re adding support for floating point atomics, would it be possible for you to add support for atomic operations on pointers too? Currently, front ends need to bitcast pointers to an integer type which assumes that a corresponding integer type exists (it doesn’t for us) and loses pointerness of the operand in the middle, making life annoying for garbage collection. David
Philip Reames via llvm-dev
2015-Dec-14 19:44 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
On 12/13/2015 01:03 PM, David Chisnall wrote:> Hi Philip, > >> On 11 Dec 2015, at 02:22, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Currently, we limit atomic loads and stores to either pointer or integer types. I would like to propose that we extend this to allow both floating point and vector types which meet the other requirements. (i.e. power-of-two multiple of 8 bits, and aligned) > If you’re adding support for floating point atomics, would it be possible for you to add support for atomic operations on pointers too? Currently, front ends need to bitcast pointers to an integer type which assumes that a corresponding integer type exists (it doesn’t for us) and loses pointerness of the operand in the middle, making life annoying for garbage collection.Currently, our support for atomics on pointers is mixed. Atomic loads and stores of pointer types are supported. atomicrmw and cmpxchg operations on pointers not. I know of no reason for the distinction. I agree that making the change you're proposing is valuable. If you want to file a bug and assign it me, I'll likely get to it in the next couple of weeks. Alternatively, I'd be happy to review patches. :)> > David >
Maybe Matching Threads
- RFC: Extending atomic loads and stores to floating point and vector types
- RFC: Extending atomic loads and stores to floating point and vector types
- RFC: Extending atomic loads and stores to floating point and vector types
- RFC: Atomic LL/SC loops in LLVM revisited
- RFC: Extending atomic loads and stores to floating point and vector types