summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/expression_command/call-function
diff options
context:
space:
mode:
authorAdam Nemet <anemet@apple.com>2016-05-26 07:08:05 +0000
committerAdam Nemet <anemet@apple.com>2016-05-26 07:08:05 +0000
commitc68534bd13be1d79a55f26c9e3073405a0bdaa9d (patch)
treef6794fa2a1a0fbc9f1cba5138cbd6e60986cd06d /lldb/packages/Python/lldbsuite/test/expression_command/call-function
parent6f08cebf36b84d6dfb2a270e74bfd2594eaf24d7 (diff)
downloadbcm5719-llvm-c68534bd13be1d79a55f26c9e3073405a0bdaa9d.tar.gz
bcm5719-llvm-c68534bd13be1d79a55f26c9e3073405a0bdaa9d.zip
[ConstantFold] Fix incorrect index rewrites for GEPs
Summary: If an index for a vector or array type is out-of-range GEP constant folding tries to factor it into preceding dimensions. The code however does not consider addressing of structure field padding which should not qualify as out-of-range index. As demonstrated by the testcase, this can occur if the indexing performed on a vector type and the preceding index is an array type. SROA generates GEPs for example involving padding bytes as it slices an alloca. My fix disables this folding if the element type is a vector type. I believe that this is the only way we can end up with padding. (We have no access to DataLayout so I am not sure if there is actual robust way of actually checking the presence of padding.) Reviewers: majnemer Subscribers: llvm-commits, Gerolf Differential Revision: http://reviews.llvm.org/D20663 llvm-svn: 270826
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/call-function')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud