failed folding with constant array with opt -O3

I have the following simplified llvm ir, which basically returns value based on the first value of a constant array.

One of my coworkers ran across a very similar case as well. He's still reducing his test case to identify the problematic area, but based on the initial results, it looks like we have an overly conservative aliasing result being returned for two locations in disjoint elements of an array. Your example is slightly different, but an imprecise alias query (i.e. not recognizing that the load is completely covered by the store) might explain it as well.

If you could file a bug with your example, that would be helpful. If you can further reduce it that would be nice, but you've already gotten it down small enough to be useful. Thanks.


Looking at the -debug output of opt shows that SROA was skipped due to missing target data.

Adding something like:

target datalayout = "e-p:32:32:32-i32:32:32"

to the top seems sufficient to fix the issue at -O3.

By defining the size and storage requirements for i32 SROA is capable of rewriting the array load into a constant scalar load which can then be further optimized.


I came in to an email this morning that said basically the same thing for the reduced example we were looking at. However, the original IR it came from (before hand reduction) had the data layout set correctly, so there's probably still *something* going on. It's just not what I thought at first. :slight_smile:


Thanks for your help! Providing data layout works for the example I have.

I also feel there is still something else going on during the investigation.

I have another simple ir, which basically does the same thing as the original example except initialize the array element by element instead of by an constant array.

GVN relies on alias analysis passes which are implied by -O2 but not -gvn.
If you look at the tests in test/Transforms/GVN/ the call is usually to opt -basicaa -gvn. Could you try adding -basicaa (basic alias analysis) to your example ?

Best regards,

Adding some form of alias analysis like -basicaa to the list should solve the clobbering issue.

You're probably also interested in some the following to get your code completely optimized again: -constprop -simplifycfg -dse


Thanks for the inputs! Adding basicaa works. And extra transforms got the ideal optimized code.

I originally thought GVN has AG dependency on alias analysis, so it should get the expected elimination. While digging into the code, it turned out that NoAA is provided to GVN by default. Therefore, to get meaningful results from GVN, basicaa is needed.

In summary, to get the original ir to the optimized code, there are two sets of transformations. One is through sroa, which needs the target layout; and the other is using gvn, which needs a nontrivia aa.

Any thoughts on which one is cheaper in computational cost to eliminate the load? sroa seems the one to me.