diff options
| author | Matt Arsenault <Matthew.Arsenault@amd.com> | 2020-02-13 15:08:59 -0500 |
|---|---|---|
| committer | Matt Arsenault <arsenm2@gmail.com> | 2020-03-10 23:34:10 -0400 |
| commit | c0ad75e7587d2e08ba2d5c55311b44ce7f9b20e4 (patch) | |
| tree | 59307e9276a9b98abd6c1b149f0d3283074303e0 /llvm/lib/Support/APFloat.cpp | |
| parent | b17a81f8b23b8412c1fa663c9bbe60060a494503 (diff) | |
| download | llvm-c0ad75e7587d2e08ba2d5c55311b44ce7f9b20e4.zip llvm-c0ad75e7587d2e08ba2d5c55311b44ce7f9b20e4.tar.gz llvm-c0ad75e7587d2e08ba2d5c55311b44ce7f9b20e4.tar.bz2 | |
GlobalISel: Don't try to narrow extending loads/trunc store
If the loaded memory size was smaller than the result size, this would
produce out of bounds memory accesses. I'm wondering if we need a
distinct narrow memory legalize action type, since a case I care about
is decomposing a 4-byte unaligned access into 4 extending loads, which
would leave the original result register type. I'm currently awkwardly
using narrowScalar to handle unaligned accesses that need to be split.
Diffstat (limited to 'llvm/lib/Support/APFloat.cpp')
0 files changed, 0 insertions, 0 deletions