LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 46591 - load-store-vectorizer cannot assume that an offset calculated from add nuw is fine in general
Summary: load-store-vectorizer cannot assume that an offset calculated from add nuw is...
Status: NEW
Alias: None
Product: libraries
Classification: Unclassified
Component: Scalar Optimizations (show other bugs)
Version: trunk
Hardware: PC All
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-05 05:37 PDT by Juneyoung Lee
Modified: 2020-10-11 21:20 PDT (History)
7 users (show)

See Also:
Fixed By Commit(s):

Attachments
Input & output (1.90 KB, text/plain)
2020-07-05 05:37 PDT, Juneyoung Lee 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Juneyoung Lee 2020-07-05 05:37:57 PDT 
Created attachment 23680 [details]
Input & output

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.
Comment 1 Eli Friedman 2020-10-11 21:20:26 PDT 
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.