[LLVMdev] Alias analysis issue with structs on PPC

[Olivier H Sallenave]

Hi,

I have the following C loop to vectorize:

struct box {
    double* source;
};

void test(double* restrict result, struct box my_struct, int len)
{
    for (int i=0 ; i<len; i++) {
        result[i] = my_struct.source[i] * my_struct.source[i];
    }
}

There are two references in the loop, result[i] (restrict) and
my_struct.source[i] (readonly). The compiler should easily figure out that
they do not alias.

Compiling for x86, the loop alias analysis works just fine:
  AST: Alias Set Tracker: 2 alias sets for 2 pointer values.
  AliasSet[0x7fd8e2f32290, 1] must alias, No access Pointers: (double*
%arrayidx5, 18446744073709551615)
  AliasSet[0x7fd8e2f322e0, 1] must alias, No access Pointers: (double*
%arrayidx, 18446744073709551615)

Compiling for PPC with -target powerpc64le-ibm-linux-gnu, the two addresses
now alias:
  AST: Alias Set Tracker: 1 alias sets for 2 pointer values.
  AliasSet[0x7f931bd5bdc0, 2] may alias, No access Pointers: (double*
%arrayidx5, 18446744073709551615), (double* %arrayidx,
18446744073709551615)

BasicAA is used for both targets by default. The difference is that in PPC,
the IR obtained from Clang takes an i64 as parameter instead of a double*
for my_struct. This parameter is then coerced into double* using an
inttoptr instruction. The code in BasicAliasAnalysis.cpp which is triggered
for x86 is the following:

    // Function arguments can't alias with things that are known to be
    // unambigously identified at the function level.
    if ((isa<Argument>(O1) && isIdentifiedFunctionLocal(O2)) ||
        (isa<Argument>(O2) && isIdentifiedFunctionLocal(O1)))
      return NoAlias;

isIdentifiedFunctionLocal(V) returns true for a noalias argument (such as
result), but the other address (my_struct) must be a function argument in
order to return NoAlias, which is not the case anymore for PPC (since
my_struct is now the result from an inttoptr instruction). If I understand,
the problem is that we cannot trust the fact that locals do not alias with
restrict parameters (because the compiler could generate some locals which
alias)? If someone has suggestions about this, that would help a lot.

Thanks,
Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150313/f5c2f21b/attachment.html>