[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>
> 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>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev