summaryrefslogtreecommitdiff
path: root/lldb/test/API/python_api/module_section/TestModuleAndSection.py
diff options
context:
space:
mode:
authorCullen Rhodes <cullen.rhodes@arm.com>2021-01-16 16:08:40 +0000
committerCullen Rhodes <cullen.rhodes@arm.com>2021-02-01 12:14:59 +0000
commit8cda227432f1c9ceb63b88802ed8136da97274f1 (patch)
tree9a5c9e5737fb7ee3d2a8bc164b4c00601454bf40 /lldb/test/API/python_api/module_section/TestModuleAndSection.py
parent3b8a1d581e6e1623d046b8b8da577ec4d42a544c (diff)
[LV] Fix crash when computing max VF too early
D90687 introduced a crash: llvm::LoopVectorizationCostModel::computeMaxVF(llvm::ElementCount, unsigned int): Assertion `WideningDecisions.empty() && Uniforms.empty() && Scalars.empty() && "No decisions should have been taken at this point"' failed. when compiling the following C code: typedef struct { char a; } b; b *c; int d, e; int f() { int g = 0; for (; d; d++) { e = 0; for (; e < c[d].a; e++) g++; } return g; } with: clang -Os -target hexagon -mhvx -fvectorize -mv67 testcase.c -S -o - This occurred since prior to D90687 computeFeasibleMaxVF would only be called in computeMaxVF when a scalar epilogue was allowed, but now it's always called. This causes the assert above since computeFeasibleMaxVF collects all viable VFs larger than the default MaxVF, and for each VF calculates the register usage which results in analysis being done the assert above guards against. This can occur in computeFeasibleMaxVF if TTI.shouldMaximizeVectorBandwidth and this target hook is implemented in the hexagon backend to always return true. Reported by @iajbar. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D94869
Diffstat (limited to 'lldb/test/API/python_api/module_section/TestModuleAndSection.py')
0 files changed, 0 insertions, 0 deletions