diff options
author | Simon Tatham <simon.tatham@arm.com> | 2020-01-09 17:01:13 +0000 |
---|---|---|
committer | Simon Tatham <simon.tatham@arm.com> | 2020-01-09 17:28:37 +0000 |
commit | 06d07ec4a372b55e6fb77bf0b97964bde16a3184 (patch) | |
tree | bb127974f347ab1c862b596188bc24175298b4a8 /lldb/packages/Python/lldbsuite/test/commands/command/script/welcome.py | |
parent | 5e0bf6772e2ca450d3433fca8b47ce7bac5a6cc7 (diff) | |
download | bcm5719-llvm-06d07ec4a372b55e6fb77bf0b97964bde16a3184.tar.gz bcm5719-llvm-06d07ec4a372b55e6fb77bf0b97964bde16a3184.zip |
[Clang] Handle target-specific builtins returning aggregates.
Summary:
A few of the ARM MVE builtins directly return a structure type. This
causes an assertion failure at code-gen time if you try to assign the
result of the builtin to a variable, because the `RValue` created in
`EmitBuiltinExpr` from the `llvm::Value` produced by codegen is always
made by `RValue::get()`, which creates a non-aggregate `RValue` that
will fail an assertion when `AggExprEmitter::withReturnValueSlot` calls
`Src.getAggregatePointer()`. A similar failure occurs if you try to use
the struct return value directly to extract one field, e.g.
`vld2q(address).val[0]`.
The existing code-gen tests for those MVE builtins pass the returned
structure type directly to the C `return` statement, which apparently
managed to avoid that particular code path, so we didn't notice the
crash.
Now `EmitBuiltinExpr` checks the evaluation kind of the builtin's return
value, and does the necessary handling for aggregate returns. I've added
two extra test cases, both of which crashed before this change.
Reviewers: dmgreen, rjmccall
Reviewed By: rjmccall
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72271
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/commands/command/script/welcome.py')
0 files changed, 0 insertions, 0 deletions