Skip to content

[loop vectorizer] Auto vectorisation breaks because of bug in alias analysis. #42506

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

Closed
llvmbot opened this issue Aug 29, 2019 · 2 comments
Closed
Labels
bugzilla Issues migrated from bugzilla TBAA Type-Based Alias Analysis / Strict Aliasing

Comments

@llvmbot
Copy link
Member

llvmbot commented Aug 29, 2019

Bugzilla Link 43161
Version 9.0
OS Linux
Attachments Code posted on godbolt
Reporter LLVM Bugzilla Contributor
CC @fhahn,@hfinkel,@Meinersbur,@zygoloid

Extended Description

Hello, could you please have a look at this code posted on godbolt.org:
https://godbolt.org/z/O-O-Q7
(code also attached in case godbolt link breaks)

The problem is that inside the compute function, only the first loop vectorizes while the rest copies of it don't. But if I remove any of the for loops, then the rest vectorize successfully. The message "Cannot identify array bounds" is not helpful.

@llvmbot
Copy link
Member Author

llvmbot commented Aug 29, 2019

Discussion from llvm-dev mailing lists about this issue:

Reply from Nema, Ashutosh

"""
Seems like when you comment out a loop in “compute” function, it gets inlined, this helps LV by finding the bounds and vectorizes it.

With the presence of all the loops LAA is not able to identify the bounds for the accesses:

LAA: Can't find bounds for ptr: %arrayidx.i159 = getelementptr inbounds double, double* %30, i64 %and.i158, !dbg !​46

LAA: Can't find bounds for ptr: %arrayidx.i155 = getelementptr inbounds double, double* %36, i64 %and.i154, !dbg !​66

LAA: Can't find bounds for ptr: %arrayidx.i151 = getelementptr inbounds double, double* %42, i64 %and.i150, !dbg !​91

Its bit strange as its able to identify the bounds correctly for the first loop.

////////////////////////////////////////////////////////////////////////////////
Reply from Michael Kruse

"""
There is some weird interaction between alias-analysis and the
vectorized code. For the first loop, alias-analysis is able to
determine that "output" is not aliasing with the read-only arrays:

LAA: Processing memory accesses...
AST: Alias Set Tracker: 2 alias sets for 7 pointer values.
AliasSet[0x16a131c3120, 1] must alias, No access Pointers: (double*
%arrayidx6, unknown)
AliasSet[0x16a131c1e90, 6] may alias, No access Pointers: (double*
%arrayidx, unknown), (double* %arrayidx1, unknown), (double**
%_pointer.i, unknown), (i64* %_mask.i, unknown), (double* %arrayidx.i,
unknown), (double* %arrayidx5, unknown)

After vectorizing the first loop, it is not able to do this anymore
(did not investigate the why). When trying to vectorize the second
loop, it requires a runtime condition to guard against aliasing (for
which it needs to determine the loop bounds), but is unable to do so
because of the the and-mask of "G"/BracketAdapterWithMask:
%arrayidx.i159 --- or as SCEV: ((8 * %and.i158) + %36)

When removing one of the for-loops, the entire compute-function is
inlined into the run function and this problem is magically resolved.
Not sure why.

Would you file a bug report?

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@fhahn
Copy link
Contributor

fhahn commented May 7, 2025

All loops are now vectorized (Clang 20): https://godbolt.org/z/x44qc6xWE

Please re-open if any case is still missing

@fhahn fhahn closed this as completed May 7, 2025
@EugeneZelenko EugeneZelenko added TBAA Type-Based Alias Analysis / Strict Aliasing and removed clang Clang issues not falling into any other category labels May 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla TBAA Type-Based Alias Analysis / Strict Aliasing
Projects
None yet
Development

No branches or pull requests

3 participants