This is an archive of the discontinued LLVM Phabricator instance.

Use AA in LoopVectorize
ClosedPublic

Authored by hfinkel on Jul 19 2014, 7:58 PM.

Details

Summary

Currently, the loop vectorizer does not use the alias analysis infrastructure. Instead, it performs memory dependence analysis using ScalarEvolution-based linear dependence checks within equivalence classes derived from the results of ValueTracking's GetUnderlyingObjects.

Unfortunately, this means that:

  1. The loop vectorizer has logic that essentially duplicates that in BasicAA for aliasing based on identified objects
  2. The loop vectorizer cannot partition the space of dependency checks based on information only easily available from within AA (TBAA metadata is currently the prime example).

This means, for example, regardless of whether -fno-strict-aliasing is provided, the vectorizer will only vectorize this loop with a runtime memory-overlap check:

void foo(int *a, float *b) {

for (int i = 0; i < 1600; ++i) {
  a[i] = b[i];
}

}

This is suboptimal because the TBAA metadata already provides the information necessary to show that this check unnecessary. Of course, the vectorizer has a limit on the number of such checks it will insert, so in practice, ignoring TBAA means not vectorizing more-complicated loops that we should.

This patch causes the vectorizer to use an AliasSetTracker to keep track of the pointers in the loop. The resulting alias sets are then used to partition the space of dependency checks, and potential runtime checks; this results in more-efficient vectorizations.

When pointer locations are added to the AliasSetTracker, two things are done:

  1. The location size is set to UnknownSize (otherwise you'd not catch inter-iteration dependencies)
  2. For instructions in blocks that would need to be predicated, TBAA is removed (because the metadata might have a control dependency on the condition being speculated).

For non-predicated blocks, you can leave the TBAA metadata. This is safe because you can't have an iteration dependency on the TBAA metadata (if you did, and you unrolled sufficiently, you'd end up with the same pointer value used by two accesses that TBAA says should not alias, and that would yield undefined behavior).

Diff Detail

Event Timeline

hfinkel updated this revision to Diff 11689.Jul 19 2014, 7:58 PM
hfinkel retitled this revision from to Use AA in LoopVectorize.
hfinkel updated this object.
hfinkel edited the test plan for this revision. (Show Details)
hfinkel added reviewers: nadav, aschwaighofer.
hfinkel added a subscriber: Unknown Object (MLST).

LGTM.

Thanks Hal!

hfinkel accepted this revision.Jul 20 2014, 4:16 PM
hfinkel added a reviewer: hfinkel.

(will close).

This revision is now accepted and ready to land.Jul 20 2014, 4:16 PM
hfinkel closed this revision.Jul 20 2014, 4:17 PM

r213486, thanks!

nadav edited edge metadata.Jul 20 2014, 7:51 PM

Hi Hal,

Sorry for the delay in response. The motivation for this change is clear and the direction makes sense. Quick question: did you measure the effect of this change on the mailing list? Were there any performance wins or losses?

Thanks,
Nadav

  • Original Message -----

From: "Nadav Rotem" <nrotem@apple.com>
To: hfinkel@anl.gov, aschwaighofer@apple.com, nrotem@apple.com
Cc: llvm-commits@cs.uiuc.edu
Sent: Sunday, July 20, 2014 9:51:36 PM
Subject: Re: [PATCH] Use AA in LoopVectorize

Hi Hal,

Sorry for the delay in response. The motivation for this change is
clear and the direction makes sense. Quick question: did you measure
the effect of this change on the mailing list? Were there any
performance wins or losses?

You mean in the test suite? I saw nothing significant either way.

Performance wise, things should be strictly better than before. I have a number of internal benchmarks that improved for two reasons:

  1. Loops accessing many different arrays, some of different types, now require fewer checks (and thus now vectorize when they didn't before).
  2. The loop being vectorized was an inner loop that, at runtime, had a relatively small trip count; the elimination of the unnecessary dependency checks was significant.

Thanks again,
Hal

Thanks,
Nadav

http://reviews.llvm.org/D4599