Page MenuHomePhabricator
Feed Advanced Search

Jan 13 2016

vaivaswatha retitled D16140: [GlobalsAA] Relax condition in checking globals as args to functions from to [GlobalsAA] Relax condition in checking globals as args to functions.
Jan 13 2016, 2:42 AM

Jan 12 2016

vaivaswatha added a reviewer for D15922: [Cloning] cloneLoopWithPreheader(): add assert to ensure no sub-loops: anemet.
Jan 12 2016, 7:46 PM
vaivaswatha added a comment to D15922: [Cloning] cloneLoopWithPreheader(): add assert to ensure no sub-loops.

Ping !

Jan 12 2016, 7:45 PM

Jan 6 2016

vaivaswatha retitled D15922: [Cloning] cloneLoopWithPreheader(): add assert to ensure no sub-loops from to [NOP][Cloning] Add comment to cloneLoopWithPreheader() mentioning that it does not update LoopInfo for sub-loops..
Jan 6 2016, 5:58 AM
vaivaswatha abandoned D15665: GlobalsAA: InaccessibleMemOnly does not mean ReadNone..
Jan 6 2016, 5:37 AM
vaivaswatha abandoned D15777: [GlobalOpt] Globals used only in "main" can more easily be localized.
Jan 6 2016, 5:37 AM
vaivaswatha added a comment to D15919: Revert "GlobalsAA: Take advantage of ArgMemOnly, InaccessibleMemOnly and InaccessibleMemOrArgMemOnly attributes".

Thanks for doing this.

Jan 6 2016, 4:10 AM

Jan 4 2016

vaivaswatha added a comment to D15665: GlobalsAA: InaccessibleMemOnly does not mean ReadNone..

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.

Jan 4 2016, 6:38 PM
vaivaswatha updated the diff for D15665: GlobalsAA: InaccessibleMemOnly does not mean ReadNone..

Updating comment and test case as per review comment.

Jan 4 2016, 6:33 PM

Dec 25 2015

vaivaswatha retitled D15777: [GlobalOpt] Globals used only in "main" can more easily be localized from to [GlobalOpt] Globals used only in "main" can more easily be localized.
Dec 25 2015, 6:54 AM

Dec 21 2015

vaivaswatha added a comment to D15665: GlobalsAA: InaccessibleMemOnly does not mean ReadNone..

Ping !

Dec 21 2015, 6:45 PM

Dec 19 2015

vaivaswatha retitled D15665: GlobalsAA: InaccessibleMemOnly does not mean ReadNone. from to GlobalsAA: InaccessibleMemOnly does not mean ReadNone..
Dec 19 2015, 12:56 AM

Dec 18 2015

vaivaswatha added a comment to D15605: GlobalsAA: Take advantage of ArgMemOnly, InaccessibleMemOnly and InaccessibleMemOrArgMemOnly attributes.

@jmolloy Thank you for the review.

Dec 18 2015, 3:16 AM
vaivaswatha committed rL255994: GlobalsAA: Take advantage of ArgMemOnly, InaccessibleMemOnly and….
GlobalsAA: Take advantage of ArgMemOnly, InaccessibleMemOnly and…
Dec 18 2015, 3:06 AM
vaivaswatha closed D15605: GlobalsAA: Take advantage of ArgMemOnly, InaccessibleMemOnly and InaccessibleMemOrArgMemOnly attributes.
Dec 18 2015, 3:06 AM

Dec 17 2015

vaivaswatha retitled D15605: GlobalsAA: Take advantage of ArgMemOnly, InaccessibleMemOnly and InaccessibleMemOrArgMemOnly attributes from to GlobalsAA: Take advantage of ArgMemOnly, InaccessibleMemOnly and InaccessibleMemOrArgMemOnly attributes.
Dec 17 2015, 1:30 AM

Dec 16 2015

vaivaswatha committed rL255778: Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes.
Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes
Dec 16 2015, 8:19 AM
vaivaswatha closed D15499: Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes by committing rL255778: Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes.
Dec 16 2015, 8:19 AM
vaivaswatha retitled D15499: Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes from Add AlmostReadNone and AlmostArgMemOnly attributes to Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes.
Dec 16 2015, 2:50 AM
vaivaswatha retitled D15499: Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes from Add AlmostReadNone and AlmostArgMemOnly attributes and set it for a few libc functions. Enhance GlobalsAA to Add AlmostReadNone and AlmostArgMemOnly attributes.
Dec 16 2015, 2:49 AM
vaivaswatha updated the diff for D15499: Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes.

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

Dec 16 2015, 2:35 AM

Dec 14 2015

vaivaswatha committed rL255615: NFC: Fix typo in comment.
NFC: Fix typo in comment
Dec 14 2015, 8:44 PM
vaivaswatha added a comment to D15499: Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes.

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

Dec 14 2015, 6:22 PM
vaivaswatha retitled D15499: Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes from to Add AlmostReadNone and AlmostArgMemOnly attributes and set it for a few libc functions. Enhance GlobalsAA.
Dec 14 2015, 8:33 AM

Dec 12 2015

vaivaswatha added a comment to D15185: AlignmentFromAssumptions and SLPVectorizer preserves AA and GlobalsAA.

Thank you very much for closing this Hal.

Dec 12 2015, 5:12 AM

Dec 9 2015

vaivaswatha added a comment to D15185: AlignmentFromAssumptions and SLPVectorizer preserves AA and GlobalsAA.

LGTM.

Dec 9 2015, 2:02 AM

Dec 8 2015

vaivaswatha added a comment to D15185: AlignmentFromAssumptions and SLPVectorizer preserves AA and GlobalsAA.

Ping

Dec 8 2015, 8:48 PM

Dec 3 2015

vaivaswatha added a comment to D15185: AlignmentFromAssumptions and SLPVectorizer preserves AA and GlobalsAA.

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

Dec 3 2015, 7:01 AM
vaivaswatha retitled D15185: AlignmentFromAssumptions and SLPVectorizer preserves AA and GlobalsAA from to AlignmentFromAssumptions and SLPVectorizer preserves AA and GlobalsAA.
Dec 3 2015, 4:19 AM

Aug 27 2015

vaivaswatha added a comment to D11725: [SCEV] Consistently Handle Expressions That Cannot Be Divided.

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.

Aug 27 2015, 8:36 PM

Aug 16 2015

vaivaswatha added a comment to D11771: Fix how DependenceAnalysis calls de-linearization.

@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?

Aug 16 2015, 2:50 AM

Aug 14 2015

vaivaswatha updated the diff for D11771: Fix how DependenceAnalysis calls de-linearization.

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

Aug 14 2015, 8:36 AM

Aug 12 2015

vaivaswatha added inline comments to D11771: Fix how DependenceAnalysis calls de-linearization.
Aug 12 2015, 4:21 AM

Aug 11 2015

vaivaswatha added a reviewer for D11771: Fix how DependenceAnalysis calls de-linearization: grosser.
Aug 11 2015, 9:07 PM
vaivaswatha added a comment to D11725: [SCEV] Consistently Handle Expressions That Cannot Be Divided.

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

Aug 11 2015, 9:04 PM

Aug 5 2015

vaivaswatha updated the diff for D11771: Fix how DependenceAnalysis calls de-linearization.

Added changes in DependenceAnalysis.h

Aug 5 2015, 8:44 PM
vaivaswatha retitled D11771: Fix how DependenceAnalysis calls de-linearization from to Fix how DependenceAnalysis calls de-linearization.
Aug 5 2015, 10:36 AM

May 29 2015

vaivaswatha added a comment to D9698: [DependenceAnalysis] Extend unifySubscriptType for handling coupled subscript groups..

Done.

May 29 2015, 11:08 PM

May 28 2015

vaivaswatha added a comment to D9698: [DependenceAnalysis] Extend unifySubscriptType for handling coupled subscript groups..

LGTM

May 28 2015, 2:46 AM

May 18 2015

vaivaswatha added a comment to D9698: [DependenceAnalysis] Extend unifySubscriptType for handling coupled subscript groups..

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

May 18 2015, 5:25 AM

May 12 2015

vaivaswatha added a comment to D9698: [DependenceAnalysis] Extend unifySubscriptType for handling coupled subscript groups..

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

May 12 2015, 9:29 PM
vaivaswatha retitled D9698: [DependenceAnalysis] Extend unifySubscriptType for handling coupled subscript groups. from to [DependenceAnalysis] Extend unifySubscriptType for handling coupled subscript groups..
May 12 2015, 2:47 AM