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>
Philip Reames via llvm-dev
2015-Dec-14 19:46 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
On 12/12/2015 01:44 PM, JF Bastien wrote:> On Sat, Dec 12, 2015 at 1:24 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > Patch posted for review: http://reviews.llvm.org/D15471 > > > Looking at the patch, I think we should do FP only for now as vectors > have extra complexities which IMO warrant more discussion.I'm fine with splitting the patch up to make progress. I'll post a split patch shortly. Would you mind explaining what complexities you see for vectors? As per my direct email, the set of vectors which can practically be made atomic may be smaller than we'd like, but the existing atomic semantics seem to map cleanly. What am I missing? Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151214/2c2f68d5/attachment.html>
JF Bastien via llvm-dev
2015-Dec-14 20:46 UTC
[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
On Mon, Dec 14, 2015 at 11:46 AM, Philip Reames <listmail at philipreames.com> wrote:> > > On 12/12/2015 01:44 PM, JF Bastien wrote: > > On Sat, Dec 12, 2015 at 1:24 AM, Philip Reames <listmail at philipreames.com> > wrote: > >> Patch posted for review: http://reviews.llvm.org/D15471 > > > Looking at the patch, I think we should do FP only for now as vectors have > extra complexities which IMO warrant more discussion. > > I'm fine with splitting the patch up to make progress. I'll post a split > patch shortly. >Thanks. FWIW I think we'll want to do vectors, but I think it's trickier than just FP. Would you mind explaining what complexities you see for vectors? As per my> direct email, the set of vectors which can practically be made atomic may > be smaller than we'd like, but the existing atomic semantics seem to map > cleanly. What am I missing? >I'm also concerned about: - Alignment is the big one, I think we'll want to discuss having entirely atomic vectors as well as vectors whose elements are atomic only. - Having vectors of pointers without fully supporting atomic pointer. - Vectors of unusual sizes or integer types being atomic, and how they get legalized. e.g. <3 x i32> or <256 x i1>. - Once we add vector, should we consider adding other composite types in general, including structs? C++ allows this, but has substantial issues w.r.t. padding. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151214/5971cffb/attachment.html>
Possibly Parallel 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: Extending atomic loads and stores to floating point and vector types
- RFC: Extending atomic loads and stores to floating point and vector types