aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support
diff options
context:
space:
mode:
authorEli Friedman <efriedma@quicinc.com>2020-05-06 12:06:29 -0700
committerEli Friedman <efriedma@quicinc.com>2020-05-11 17:39:00 -0700
commitc9c930ae67c38b93451aa979de723723aec0067d (patch)
tree627a5bddc7d4822ea792a6dd567c263544454266 /llvm/lib/Support
parent117e5609e98b43f925c678b72f816ad3a1c3eee7 (diff)
downloadllvm-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/lib/Support')
0 files changed, 0 insertions, 0 deletions