diff options
author | Eli Friedman <efriedma@quicinc.com> | 2020-05-06 12:06:29 -0700 |
---|---|---|
committer | Eli Friedman <efriedma@quicinc.com> | 2020-05-11 17:39:00 -0700 |
commit | c9c930ae67c38b93451aa979de723723aec0067d (patch) | |
tree | 627a5bddc7d4822ea792a6dd567c263544454266 /llvm/utils/FileCheck/FileCheck.cpp | |
parent | 117e5609e98b43f925c678b72f816ad3a1c3eee7 (diff) | |
download | llvm-c9c930ae67c38b93451aa979de723723aec0067d.zip llvm-c9c930ae67c38b93451aa979de723723aec0067d.tar.gz llvm-c9c930ae67c38b93451aa979de723723aec0067d.tar.bz2 |
[SelectionDAG] Don't promote the alignment of allocas beyond the stack alignment.
allocas in LLVM IR have a specified alignment. When that alignment is
specified, the alloca has at least that alignment at runtime.
If the specified type of the alloca has a higher preferred alignment,
SelectionDAG currently ignores that specified alignment, and increases
the alignment. It does this even if it would trigger stack realignment.
I don't think this makes sense, so this patch changes that.
I was looking into this for SVE in particular: for SVE, overaligning
vscale'ed types is extra expensive because it requires realigning the
stack multiple times, or using dynamic allocation. (This currently isn't
implemented.)
I updated the expected assembly for a couple tests; in particular, for
arg-copy-elide.ll, the optimization in question does not increase the
alignment the way SelectionDAG normally would. For the rest, I just
increased the specified alignment on the allocas to match what
SelectionDAG was inferring.
Differential Revision: https://reviews.llvm.org/D79532
Diffstat (limited to 'llvm/utils/FileCheck/FileCheck.cpp')
0 files changed, 0 insertions, 0 deletions