[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types

JF Bastien via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 14 12:46:21 PST 2015


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>


More information about the llvm-dev mailing list