diff options
| author | Amara Emerson <aemerson@apple.com> | 2020-04-24 12:05:44 -0700 |
|---|---|---|
| committer | Amara Emerson <aemerson@apple.com> | 2020-04-24 13:56:43 -0700 |
| commit | dbb035677103c0b903b78a561b74b5fb4de3dc99 (patch) | |
| tree | 79a815196941727213dd37e40b2eba8dbacf2db4 /llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp | |
| parent | 38a9528ca238c7034b4d8f4c30e0357f2cd71fda (diff) | |
| download | llvm-dbb035677103c0b903b78a561b74b5fb4de3dc99.zip llvm-dbb035677103c0b903b78a561b74b5fb4de3dc99.tar.gz llvm-dbb035677103c0b903b78a561b74b5fb4de3dc99.tar.bz2 | |
[AArch64][GlobalISel] Fix sub-64b stack parameter passing on Darwin.
A previous bug fix for varargs introduced a regression where we would
incorrectly widen some stores to memory when passing i8/i16 parameters on the
stack. This didn't show up seemingly because it only happens when there is
no signext/zeroext parameter attribute, which I think for Darwin clang adds.
Swift however seems to be a different story, and a plain anyext on the parameter
triggered the bug.
To fix this, I've added a new ValueHandler::assignValueToAddress type override
which lets us distiguish between varargs and fixed args (we still need this
widening behaviour for varargs to fix the original bug in 2018).
rdar://61353552
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp')
0 files changed, 0 insertions, 0 deletions