[PATCH] D86669: [ValueTracking] Remove MaxLookup from getUnderlyingObjects

[Ting Wang via Phabricator via llvm-commits]

tingwang added a comment.

We hit upon one test case (attached test.ll) blocked by this MaxLookup: the default value of MaxLookup is not enough to identify the underlying object, and the alias info added by AddAliasScopeMetadata() is wrong, resulting in wrong schedule decisions in machine-scheduler.

In function widget, pointer %tmp147 in below instruction is not correctly identified by getUnderlyingObjects()

  %tmp148 = load i32, i32* %tmp147, align 4, !alias.scope !25, !noalias !26

The chain of pointers is below:

  store [0 x %struct.ham.2]* %arg, [0 x %struct.ham.2]** %tmp, align 8
  %tmp123 = load [0 x %struct.ham.2]*, [0 x %struct.ham.2]** %tmp, align 8
  %tmp127 = bitcast [0 x %struct.ham.2]* %tmp123 to i8*
  %tmp128 = getelementptr i8, i8* %tmp127, i64 %tmp126
  %tmp136 = getelementptr inbounds i8, i8* %tmp128, i64 %tmp135
  %tmp137 = bitcast i8* %tmp136 to [24 x i8]*
  %tmp138 = bitcast [24 x i8]* %tmp137 to %struct.ham.2*
  %tmp139 = getelementptr inbounds %struct.ham.2, %struct.ham.2* %tmp138, i32 0, i32 1
  %tmp140 = bitcast [4 x %struct.spam.3]* %tmp139 to i8*
  %tmp141 = getelementptr i8, i8* %tmp140, i64 -4
  %tmp146 = getelementptr inbounds i8, i8* %tmp141, i64 %tmp145
  %tmp147 = bitcast i8* %tmp146 to i32*

It looks like there is real program affected by this hard limit, and it produced wrong result. Can we think about this twice?

By the way, I used below command line to reproduce the issue.

  opt --vector-library=MASSV -passes=default<O3> -aa-pipeline=default -mcpu=pwr9 -o test.err.bc test.ll 

F23328194: test.ll <https://reviews.llvm.org/F23328194>


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86669/new/

https://reviews.llvm.org/D86669