[Exclusivity] Add new dominating access checks in loop pre-headers

[shajrawi]

radar rdar://problem/45736229

General case:

A = ref_element_addr

begin_access A [dynamic] [no_nested_conflict]

Adding an empty begin_access A in the preheader would allow us to turn the loop's access to [static]

This improves the performance of matrix multiplication by 2X

[shajrawi]

@swift-ci Please test

[shajrawi]

@eeckstein , @atrick Can either one of you please review?

[atrick]

I don't see any major issues, but I don't want to claim that I've fully reviewed it yet. I have some clarification request and style suggestions:

1. I thought you would potentially need to rerun the normal dominated check removal after loop dominated removal. Can you come up with an example where that's needed, or do you want to put that off as a TODO for later? It seems possible that this will create redundant accesses in the preheader.

2. LoopDominatedAccessAdder makes some key assumptions. They should be explicitly stated somewhere:

• Precondition: There are no unpaired accesses (or keypath accesses) anywhere in the function.

• Invariant: An access scope cannot begin outside the loop and end on any path between the loop header and the original dominated access.

• Expectation: Accesses will be hoisted across nested loops during bottom-up processing.

[atrick]

currnet typo.

[atrick]

Use getParentBlock instead of duplicating all this code. It works for instructions and arguments.

[atrick]

You can replace this whole function with a call to getParentBlock followed by a single domanince check between the operand's block and the preheader block. Also, I think this dominance check should be an assert, if I understand the preconditions.

[shajrawi]

Thanks @atrick - I changed the PR based on your comments and explicitly stated the assumptions you mentioned.
re rerun the normal dominated check removal: I don't think we need to do rerun it, or that there's a case wherein that will expose new potential, I added the following TODO / Comment explaining it -

    // TODO: Do we need to rerun the normal dominated check removal here?
    // I don’t think we need to do so: there shouldn’t be any redundant
    // accesses in the preheader that we can eliminate:
    // We only create a single access no matter how many accesses to
    // the same storage are inside the loop.
    // If there was an access outside of the loop then no new potential
    // would have been exposed by LoopDominatingAccessAdder?

[shajrawi]

@swift-ci Please test