[PATCH] D10476: Additional fix for PR14269: Clang crashes when a bit field is used as inline assembler input / output with memory constraint

[Eric Christopher]

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