Lanai side looks good to me, thanks!

In D63958#1564692, @spatel wrote:

In D63958#1564460, @RKSimon wrote:

Apart from the Lanai code (which like @spatel I know very little about) everything LGTM

I'm not finding any docs for this target other than the code in LLVM itself. Discussion about whether this target should be included in LLVM from when it first appeared in trunk:
http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html

From commit activity, maybe only @jpienaar can say what is happening on that target?

FWIW, there's a more involved version of this transform already in IR (in instcombine although that seems misplaced to me) - see "swapMayExposeCSEOpportunities()".

This make the declaration of ConstIterator and Iterator equivalent (line 107), so SGTM.

Change to Lanai seems fine. The model for Lanai execution/usage means atomics aren't important, but treating them conservatively is better. Thanks!

Looks good and as discussed the regression will be addressed by using carry.

Removed some unrelated renames.

Didn't mean to have this send out emails yet, some spurious changes that I want to revert still.

@MatzeB I'll take a swing at updating those later and sending you a review (traveling, so response time variable).

Looks good, thanks!

Looks good for Lanai changes

In D29605#668363, @majnemer wrote:

In D29605#668334, @majnemer wrote:

Hmm, this is the sort of thing I'd expect SelectionDAG to "just do"... Do other backends achieve the same end by similar means?

Add computeKnownBitsForTargetNode for Lanai.

I'll submit it.

Thanks. Could you run this through clang/tools/clang-format-diff.py before committing?

Thanks!

Expand test to test lowering of ashldi.

Updated the pseudo code variable names to correspond better with actual variable names used.

Updated to test the type before matching R0 and R1.

LGTM

Looks good to me, do you need help submitting?

Cool. I didn't know the review system allows having the patch updated like this :) It still reports me as the author and you as a subscriber. I don't think that matters.

Oh, sorry, I didn't see your response before I clicked abandoned. It has been a while, so this patch is pretty stale.

SG, will do cleanup separately.

Looks good, thanks.

Comments addressed, thanks.

In D21726#467239, @ab wrote:

In D21726#467230, @ab wrote:

Also, I see BPF doesn't need any changes; can you confirm?

Looks like Lanai will though; I suppose that can be done separately.

Updated, thanks

Updated to address comments.

Friendly ping

@mcrosier: Yes indeed, funny things can happen if these are wrong :). Added a IR test to test some of the different code paths in areMemAccessesTriviallyDisjoint.

Adding simple test case to verify effect on scheduling DAG due to areMemAccessesTriviallyDisjoint change.