Pol Marcet =?utf-8?q?Sardà ?= <polmarcetsa...@gmail.com>,
Pol Marcet =?utf-8?q?Sardà ?= <polmarcetsa...@gmail.com>,Pol M
<polmarcetsa...@gmail.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/76...@github.com>
================
@@ -10895,6 +10899,132 @@ bool VectorExprEvaluator::VisitUnaryOperator(const
UnaryOperator *E) {
return Success(APValue(ResultElements.data(), ResultElements.size()), E);
}
+static bool EvaluateVectorOrLValue(APValue &Result, EvalInfo &Info,
----------------
sethp wrote:
I've dealt with lvalues in the interpreter, but maybe only a little more than
you have. I've found it more than a little confusing, especially because
interpreter seemingly uses "RValue" as a synonym for "actual value" (as you're
using it here), and "LValue" as "opaque blob of bytes" (with metadata, and
accessors, but enough wrinkles that it's just easier to convert to an RValue to
work with the actual data).
That said, I think there's two ways to go here to meet the need instead of this
function:
1. Teach the parser that these builtins ought to take their arguments as
rvalues, so that it will insert a `LValueToRValue` cast in the expression tree
wrapping the src value, and so you can use `EvaluateVector` (probably loosening
its assertion to allow `xvalue`s too). This probably would have downstream
consequences, though, and I lack the expertise to know whether they'd be good
or bad. But it might be interesting!
2. Use, as much of the interpreter seems to, `EvaluateAsRValue` as shorthand
for "do an in-place 'dereference' of the lvalue": the main difference I see
from `EvaluateVectorOrLValue` here is that the latter checks for an impossible
condition (SemaChecking.cpp already prevents construction of any
[ConvertVectorExpr](https://github.com/llvm/llvm-project/blob/2e08e821b7ea5bf7c0fe0775feb94a7fdb5204c7/clang/lib/Sema/SemaChecking.cpp#L9428-L9435)
or
[ShuffleVectorExpr](https://github.com/llvm/llvm-project/blob/2e08e821b7ea5bf7c0fe0775feb94a7fdb5204c7/clang/lib/Sema/SemaChecking.cpp#L9351-L9356)
that doesn't have vector-typed arguments in the appropriate slots).
For the latter path, it might be wise to add a test case to exercise the
checker, too; perhaps something like this for `__builtin_convertvector`?
```c++
static_assert([]{
__builtin_convertvector(0, vector8char); // expected-error {{must be a
vector}}
__builtin_convertvector((vector8char){}, int); // expected-error {{must be
of vector type}}
return 1;
}());
```
(and similar for `__builtin_shufflevector`)
https://github.com/llvm/llvm-project/pull/76615
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
