In D71617#1921143, @uenoku wrote:

I think the title should be more descriptive, like "improve noalias preservation using reachability" or something.

In D71617#1921067, @jdoerfert wrote:

@pgode Can you modify the title (this is not a WIP and not a NFC patch).

Updated the patch on top on Hideto's changes.
Added description to the test in noalias.ll.
Needed to increase the max-iterations for nonnull.ll

In D71617#1919565, @uenoku wrote:

It was caused by a bug that the dependence track was missing for NoAliasAA so I have pushed the fix. (https://github.com/llvm/llvm-project/commit/d9bf79f4e9952acca1fa353e39bcee89cd69550f)

Additional conditions are included. Added new test.

In D71617#1911979, @jdoerfert wrote:

@pgode Are you still looking into this? Do you need feedback from me?

Thanks for the explanation. I thought the exact opposite i.e. even though the use is potentially captured in the callee but the callsite of callee is reachable, so we propagate noalias. I apologize as I had basic incorrect understanding.

Thanks for reviewing further.

• Removed the Dependence flag.
• For the conditions to return 'true', in Pred: I observe that the correct condition should be below. This condition means that callsite_argument should not have nocapture and getCtxI() should be reachable from user. I think this, because for noalias propagation to happen w.r.t. (ii) condition, we should get true from checkForAllUses and Pred as well.

Updated patch which considers the review comments.

Thanks for reviewing. I understand as this was during year end.
I will make the changes and update the patch. I tried the changes locally and I think I need to further check why noalias is still propagated for other checks in pthread.ll .

Thanks @jdoerfert for detailed explanation and listing the corrections.

I have tried modifying the patch to include suggestions.

• Added condition to check if use is not marked nocapture.
• Included nullpointer check and reachability check.

Thanks for suggestions. I am learning more.

• Using AAReachability instead of AANoCapture and also removed those functions from AANoCapture.

Addressed the comments in the new diff version.

Tried addressing the comments in this patch.

• Created new methods for NoCaptureMaybeBeforeInstruction which returns true as of now. Using this method in the checkForAllUses method.
• Added additional parameter to checkForAllUses (initializing to nullptr). If this ptr is not null, then we check if use is reachable till this callsite instruction.
• Predicate checks in which case we should follow for use's user.
• checkForAllUses is called to check uses of argument. If it is valid/reachable use, then noalias deduction should happen.

Updated the patch as per review comments.

Thanks for highlighting the nit. Corrected it.

In D70233#1753619, @uenoku wrote:

It seems a bit weird for me to use IRPosition as a program point. Therefore, I think it is better to use Instruction instead of IRPosition. So the interface will be

bool isAssumedReachable(const Instruction &From, const Instruction &To)

What do you think?

Btw., do you have commit access?

Updated the function comments.

Thanks @jdoerfert for the helpful corrections. I have removed the files. (I should have removed them in the last patch.)
I will start working on the next part.

@jdoerfert Thank you suggesting the corrections.
Updating the corrected patch.

Thank you @jdoerfert , @sstefan1 and @uenoku for your helpful comments.
Submitting updated patch with corrections.

Thanks for splitting the code. LGTM.
Thanks.

Thanks for asking.
The first part of changes i.e. 'Fuse CMN, CMP, TST followed by Bcc', is applicable for Vulcan as well.
But, the second part i.e. 'Fuse ALU operations followed by CBZ/CBNZ' is not applicable for Vulcan, i.e. we don't fuse these. Is it possible to make this only Apple specific ?

Removed the CacheLineSize (set to 64) for Vulcan, as three other parameters are required for LoopDataPrefetch to be effective.
Will include CacheLineSize & 3 other parameters in another patch, after they are finalized.

Updated diff.
Removed fusion of additional instructions for Vulcan.
Default instructions supported by 'Macrofusion subtarget feature' will be fused.

The approach of adding a new sub-feature for Macro-op fusion, by categorizing the instructions (my presumption) doesn't seem a good option. It will end up adding too many subfeature such as FeatureMacroOpFusionArith/FeatureMacroOpFusionLogical. Please correct me.

Corrected & updated the diff.

But the code looks good to me with the extra comment removed.

Removed the extra comments (comments in 3.11 & 3.12 FP Load/store).
Modified comments part of 3.6 & 3.7 (Load/Store) to say that they are valid for 3.11 & 3.12 (FP Load/Store) as well.

Out of curiosity, what are the performance improvements with this model?

Actually, this is a functional patch and we are currently validating it on the simulators. So, we will update performance numbers later.

Eric,
While submitting, I had added 'llvm-commits' as subscriber, as per the guidelines. (>> pgode added subscribers: echristo, aemerson, MatzeB, llvm-commits.)
Additionally, I also got a mail from the list llvm-commits: 'Your message entitled [PATCH] D21728: [AARCH64] Add Broadcom Vulcan scheduling modelwas successfully received by the llvm-commits mailing list.'
I can resend the patch, if it is required. Kindly suggest.
Thanks.

Ping ?