This is an archive of the discontinued LLVM Phabricator instance.

[ConstantFolding] Fix assertion failure on non-power-of-two vector load.
ClosedPublic

Authored by foad on Jun 15 2019, 6:49 AM.

Details

Summary

The test case does an (out of bounds) load from a global constant with
type <3 x float>. InstSimplify tried to turn this into an integer load
of the whole alloc size of the vector, which is 128 bits due to
alignment padding, and then bitcast this to <3 x vector> which failed
an assertion due to the type size mismatch.

The fix is to do an integer load of the normal size of the vector, with
no alignment padding.

Change-Id: I911d744b6f048fb18df5814dfef21a9d8259aeb6

Diff Detail

Repository
rL LLVM

Event Timeline

foad created this revision.Jun 15 2019, 6:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 15 2019, 6:49 AM
Herald added a subscriber: wdng. · View Herald Transcript

The test case does an (out of bounds) load from a global constant with type <3 x float>.

Do you need an out-of-bounds access to trigger the problem?

foad added a comment.Jun 15 2019, 7:49 AM

The test case does an (out of bounds) load from a global constant with type <3 x float>.

Do you need an out-of-bounds access to trigger the problem?

Yes to prevent it from being handled earlier by llvm::ConstantFoldLoadThroughGEPConstantExpr.

arsenm accepted this revision.Jun 18 2019, 4:36 PM

LGTM with nit

test/Transforms/InstSimplify/load.ll
34 ↗(On Diff #204915)

Can you add a comment that this is an out of bounds load

This revision is now accepted and ready to land.Jun 18 2019, 4:36 PM
This revision was automatically updated to reflect the committed changes.