echristo accepted this revision. echristo added a comment. This revision is now accepted and ready to land.
In http://reviews.llvm.org/D10476#209500, @hfinkel wrote: > In http://reviews.llvm.org/D10476#203538, @andreybokhanko wrote: > > > In http://reviews.llvm.org/D10476#202740, @hfinkel wrote: > > > > > I agree; we don't want to tie frontend functionality to a specific > > > representation of the vectors. > > > > > > We could support this, but we'd need to do it by: > > > > > > 1. Creating a local stack variable (alloca) > > > 2. Extracting the requested vector element and storing it in that > > > stack-allocated memory > > > 3. Providing the address of the local stack variable to the inline asm > > > 4. After the inline asm, loading the value from the local stack variable > > > and inserting it back into the vector > > > > > > I have no opinion on whether or not this is worth implementing. > > > > > > Hal, what you suggested means basically creating a new local variable, > > copying value of a vector element to it and then providing address of this > > local variable, **not** original vector element. I'm not sure that > > preserves semantic of inline assembly's "m" restriction, as it asks for > > memory address of original variable, not some copy. > > > The real question is: Is the difference observable? When I made the > suggestion, I did so because I felt the answer was no. But this is not true > if you capture the address to use later. Thus, the difference is observable, > and I'll vote that we simply not support this case. > > > Eric, what do you think? > I agree here. Let's go with this patch right now and do anything else incrementally. Thanks! -eric http://reviews.llvm.org/D10476 _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
