Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

load-store-vectorizer cannot assume that an offset calculated from add nuw is fine in general #45936

Closed
aqjune opened this issue Jul 5, 2020 · 2 comments
Labels
bugzilla Issues migrated from bugzilla loopoptim miscompilation

Comments

@aqjune
Copy link
Contributor

aqjune commented Jul 5, 2020

Bugzilla Link 46591
Version trunk
OS All
Attachments Input & output
CC @efriedma-quic,@fhahn,@arsenm,@nunoplopes

Extended Description

test/Transforms/LoadStoreVectorizer/X86/vectorize-i8-nested-add.ll 's ld_v4i8_add_nuw vectorizes a sequence of loads, which is illegal.

https://godbolt.org/z/NzK5oY
(the attached file contains this input/output)

Counter example: if v0 and v1 is 0, nuw is never triggered, but the offsets aren't still consecutive.
https://alive2.llvm.org/ce/z/4nZKBs

This can happen when a program has an allocation larger than 4G.

@efriedma-quic
Copy link
Collaborator

I briefly looked at Vectorizer::lookThroughComplexAddresses . I think what's happening is that it's using getSExtValue() incorrectly: essentially, it's accidentally treating "zext(x+c)" as if it were "zext(x)+sext(c)", as opposed to "zext(x)+zext(c)". That throws off the rest of the math.

@nunoplopes
Copy link
Member

I think this is fixed (by 2be0abb)
The transformation is no longer performed.

cc @jlebar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla loopoptim miscompilation
Projects
None yet
Development

No branches or pull requests

3 participants