Ping !

Thanks for doing this.

In D15665#319247, @reames wrote:

I'm really not sure inaccessible memonly belongs in GlobalsAA at all. Particularly since we haven't added even basis cases to BasicAA.

In general, I think we need to be really careful when implementing this. It's fair to say that the call doesn't modify or read any *particular* LLVM value, but I'm not sure our aliasing model is correct if we say that it can't read *any* LLVM value. In particular, as you point out, inaccessiblememonly may still be modifying memory and have memory dependence.

Updating comment and test case as per review comment.

Ping !

@jmolloy Thank you for the review.

Changes as per reviews: This change now just adds the two attributes and relevant tests.

In D15499#309992, @jmolloy wrote:

Hi Vaivaswatha,

Thanks for pushing this forward. Firstly, this patch should be split into at about four separate patches:

1. Introduce new function attributes
2. Modify GlobalsAA
3. Add these new attributes to libc functions
4. Add __mulsc3

The LLVM community prefer small, targetted patches, and each should come with at least one test case.

I can do that. So the first patch can be part of this review and I'll create new ones as I go along?

There will be a lot of bikeshedding on the names for these attributes. I'll just throw my penniworth in the ring and say I don't like the current names. "almostreadnone" only tells me that it isn't readnone - I'm going to have to look at the LangRef (which needs updating as part of patch (1) by the way) to see what it means.

A well-named attribute should imply its semantics at least vaguely. "readnone" for example is self explanatory. It'd be good to replace "almost" with something that describes how it differs from "readnone".

I'd suggest having a look the commits that introduced other attributes (like "norecurse" that I added recently) - they will show you what tests need touching/adding. Adding an attribute requires more tests than a normal commit, because you change the bitcode format and we need to ensure we don't regress this.

Did you run the LLVM regression tests? I think this line:

ATTR_KIND_ALMOST_ARGMEM_ONLY = 50,

should have broken at least one test - there is an invalid bitcode test that uses "50" as a known-invalid attribute kind.

I did run the regression tests and as expected saw some failures. I am currently working on them. I'll update this patch with the corrected tests, and only covering work-item (1). Will submit more patches as it progresses.

/// @brief Determine if the function may read only non IR visible globals,

What about heap allocations or any other allocation that is considered an object, like an alloca whose address has been taken? Are we restricting this completely to globals, or do we need to expand this to cover all addressable objects?

Does "read only non-IR visible memory" sound more appropriate ?

Cheers,

James

Thank you very much for closing this Hal.

In D15185#305690, @hfinkel wrote:

LGTM.

Ping

Related mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2015-December/092972.html

What is the difference between DependenceAnalysis::tryDelinearize and ScalarEvolution::delinearize?

As far as I know, there shouldn't be a difference here regarding the actual computation. In fact, before the most recent rewrite that split the computation into 3 phases, tryDelinearize called delinearize directly. Perhaps @sebpop can provide more insight. Otherwise, I will look into restoring that feature to avoid duplication.

@hfinkel Thank you very much for the review. I don't have permission to commit to the repo. Can you please commit this on my behalf?

The assert on Src element size and Dst element size was incorrect. Fixing that.

It would be helpful if the test case attached had the source loop as a comment, similar to the other test cases for DependenceAnalysis.

Added changes in DependenceAnalysis.h

In D9698#181018, @jingyue wrote:

Done.

In D9698#179757, @jingyue wrote:

LGTM

Hi, a gentle reminder. Can anybody review this change?

I may be missing something. Why not calling unifySubscriptType(Pairs[SJ]) here? Do we have to unify the subscript types across the entire group?