Page MenuHomePhabricator

uenoku (Hideto Ueno)
User

Projects

User does not belong to any projects.

User Details

User Since
Mar 8 2019, 5:25 AM (45 w, 1 d)

Recent Activity

Tue, Jan 14

uenoku committed rG188f9a348dc5: [Attributor] AAValueConstantRange: Value range analysis using constant range (authored by uenoku).
[Attributor] AAValueConstantRange: Value range analysis using constant range
Tue, Jan 14, 11:50 PM
uenoku closed D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Tue, Jan 14, 11:49 PM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

Add the test.

Tue, Jan 14, 5:07 AM · Restricted Project

Sat, Jan 4

uenoku reopened D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

It seems the failure occurs when old pm is used.
I couldn't find what is causing this error.

@jdoerfert Could you take a look at this?

opt: /b/s/w/ir/k/llvm-project/llvm/lib/Transforms/IPO/Attributor.cpp:6475: llvm::ChangeStatus llvm::Attributor::rewriteFunctionSignatures(): Assertion `OldFn->getNumUses() == 0 && "Unexpected leftover uses!"' failed.

Should have been fixed by rGd2d2fb19f7ea.

Called function must be a pointer! call addrspace(1792) void <badref>(i32* nofree readnone undef) #10

I haven't seen this running the test suite. I'll apply your patch and take a look.

Sat, Jan 4, 12:06 AM · Restricted Project

Fri, Jan 3

uenoku added a comment to D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

It seems the failure occurs when old pm is used.
I couldn't find what is causing this error.

Fri, Jan 3, 1:13 AM · Restricted Project

Thu, Jan 2

uenoku committed rG5fc02dc0a7b6: Revert "[Attributor] AAValueConstantRange: Value range analysis using constant… (authored by uenoku).
Revert "[Attributor] AAValueConstantRange: Value range analysis using constant…
Thu, Jan 2, 6:07 PM
uenoku added a reverting change for rGe9963034314e: [Attributor] AAValueConstantRange: Value range analysis using constant range: rG5fc02dc0a7b6: Revert "[Attributor] AAValueConstantRange: Value range analysis using constant….
Thu, Jan 2, 6:06 PM
uenoku added a comment to D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

I have reverted the commit. Sorry for the mess.

Thu, Jan 2, 6:06 PM · Restricted Project

Wed, Jan 1

uenoku accepted D72017: [Attributor] AANoRecurse check all call sites for `norecurse`.

LGTM

Wed, Jan 1, 12:31 PM · Restricted Project

Tue, Dec 31

uenoku committed rGe9963034314e: [Attributor] AAValueConstantRange: Value range analysis using constant range (authored by uenoku).
[Attributor] AAValueConstantRange: Value range analysis using constant range
Tue, Dec 31, 10:44 PM
uenoku closed D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Tue, Dec 31, 10:43 PM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

Remove outdated todos.

Tue, Dec 31, 10:25 PM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

Minor update.

Tue, Dec 31, 9:57 PM · Restricted Project
uenoku accepted D72016: [Attributor] Propagate known information from `checkForAllCallSites`.

LGTM from me.

Tue, Dec 31, 8:53 AM · Restricted Project
uenoku added inline comments to D72017: [Attributor] AANoRecurse check all call sites for `norecurse`.
Tue, Dec 31, 1:02 AM · Restricted Project

Mon, Dec 30

uenoku added inline comments to D72017: [Attributor] AANoRecurse check all call sites for `norecurse`.
Mon, Dec 30, 11:57 PM · Restricted Project
uenoku added inline comments to D72017: [Attributor] AANoRecurse check all call sites for `norecurse`.
Mon, Dec 30, 11:48 PM · Restricted Project
uenoku added a comment to D71974: [Attributor][WIP] Connect AAIsDead with AAUndefinedBehavior.

Similarly, in AAUB we should go through the explorer context when we add something to the knownUB set. So if I is knownUB, make all instructions in the must-be-executed-context of I knownUB, thus insert all into the set. In AAIsDead we can then simply query isKnownUB and that will only need to look into the set (as before).

If I understand it correctly, this will mark as UB all the instructions from the UB instruction and forwards (i.e. the must be executed context goes to the successors). That will probably complicate things as to see if a BB is dead, with the current code, it makes sense to see its first instruction right?

The must-be-executed-context is not defined to only contain "successors". It might right now but that will change eventually.
I think we should stick to known information right now.

I still believe this is more complex and less general than the approach I tried to describe. Maybe the following is a good compromise in the direction I think we should going but working already right now:

  1. Since the must-be-executed-context is not collecting predecessors yet, we need to change that. The code actually exists already, it just needs to be separated from some other improvements and put for review again. I'll look into that (or @uenoku you can if you want to).

I'd like to work on it.

Mon, Dec 30, 11:47 AM · Restricted Project
uenoku added inline comments to D71960: [Attributor] AAUndefinedBehavior: AAValueSimplify in memory accessing instructions..
Mon, Dec 30, 9:19 AM · Restricted Project
uenoku added inline comments to D71960: [Attributor] AAUndefinedBehavior: AAValueSimplify in memory accessing instructions..
Mon, Dec 30, 8:03 AM · Restricted Project
uenoku committed rG34fe8d045117: [Attributor] Use `changeUseAfterManifest` in AAValueSimplify manifest (authored by uenoku).
[Attributor] Use `changeUseAfterManifest` in AAValueSimplify manifest
Mon, Dec 30, 12:16 AM
uenoku closed D71972: [Attributor] Use `changeUseAfterManifest` in AAValueSimplify manifest.
Mon, Dec 30, 12:16 AM · Restricted Project

Sun, Dec 29

uenoku added a comment to D71972: [Attributor] Use `changeUseAfterManifest` in AAValueSimplify manifest.

LGTM. FWIW, the improved AAVAlueSimplify does fold on its own.

Sun, Dec 29, 12:23 PM · Restricted Project
uenoku added inline comments to D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Sun, Dec 29, 12:14 PM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
  • add a helper function for floating value updateImpl
  • add test
    • range metadata
    • dereferenceable
  • query to AAValueConstantRange when AAValueSimplify gives up
  • call LVI and SCEV in initialize as known information
Sun, Dec 29, 12:04 PM · Restricted Project
uenoku created D71972: [Attributor] Use `changeUseAfterManifest` in AAValueSimplify manifest.
Sun, Dec 29, 1:38 AM · Restricted Project
uenoku committed rGef4febd85b54: [Attributor] AAUndefinedBehavior: Check for branches on undef value. (authored by uenoku).
[Attributor] AAUndefinedBehavior: Check for branches on undef value.
Sun, Dec 29, 12:51 AM
uenoku closed D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..
Sun, Dec 29, 12:51 AM · Restricted Project

Sat, Dec 28

uenoku added a comment to D71960: [Attributor] AAUndefinedBehavior: AAValueSimplify in memory accessing instructions..

Now, the more interesting part is actually looking what the Attributor does. If I followed the code correctly, previously we didn't query AAValueSimplify.
What happens if we do (and correct me if I'm wrong, it seems useful to me to know how it works) is that %e.2 is a floating value,
which calls genericValueTraversal(), which for the phi node, calls VisitValueCB with the 3 incoming values: null, undef and undef.
This in turn calls checkAndUpdate() which ignores UndefValue and finalizes on null (but if we had other different values, this:

if (AccumulatedSimplifiedValue.hasValue())
  return AccumulatedSimplifiedValue == QueryingValueSimplified;

in checkAndUpdate() would return false because of conflicting values, effectively indicating pessimistic fixpoint).

Now, other than that, I guess that with this:

So once AAIsDead can get to interact with AAUB, the problem will be solved.

you meant that when AAIsDead will interact with AAUB, the former will ignore the 2 phis in genericValueTraversal() since it will consider them dead.

Sat, Dec 28, 10:21 AM · Restricted Project
uenoku added a comment to D71960: [Attributor] AAUndefinedBehavior: AAValueSimplify in memory accessing instructions..

There's one test case that is worrying: IPConstantProp/PR26044.ll. With this patch, a from undef becomes load from null and I don't see the reason.

I think this is no problem. It is because of on-demand creation. It is the first time to create AAValueSimplify to a pointer operand. The deduction is like this:

  1. The assumption which claims "for.cond1 is dead" is rejected because AAIsDead doesn't know there is UB.
  2. %e.2 is simplified to null because %e.2 can be null or undef.
  3. %e.2 is replaced with null in manifest
Sat, Dec 28, 8:27 AM · Restricted Project
uenoku accepted D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

LGTM again, thank you! I'll commit.

Sat, Dec 28, 6:47 AM · Restricted Project

Fri, Dec 27

uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..
  • Attributor::getPointerOperand() and getPointerOperandOfNonVolatile().
  • Removed AAValueSimplify for memory accessing instructions.
  • Updated test cases.

    Notes:
  • As it seems, there are multiple instances of getPointerOperand() across LLVM. We should probably be careful and not name a function like this, hence I put getPointerOperand() as a static method of Attributor. You may want to check this, although it's somewhat old and probably outdated.
  • @uenoku I updated the test cases according to what I thought they tried to test. Please verify that they're correct because I may very well have misinterpreted.
Fri, Dec 27, 8:54 PM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

Well, if we go by the book, which would be the LLVM IR ref manual, and optimize aggressively for UB, undef can be considered to have any bit pattern.
And we can choose it to have the null bit pattern, which is UB for both volatile and non-volatile.

Ok, thanks.

Fri, Dec 27, 7:35 AM · Restricted Project

Thu, Dec 26

uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..
  • I still don't understand why getPointerOperand() returns null on volatile instructions (although I have guess it is to prevent further processing). Is it correct what I do?

getPointerOperand was added as a helper for dereferenceable(volatile store/load doesn't imply dereferenceable). And you can change it if you want.

Thu, Dec 26, 11:57 PM · Restricted Project
uenoku added inline comments to D71910: [Attributor] Add helper to change an instruction to `unreachable` inst.
Thu, Dec 26, 10:06 AM · Restricted Project
uenoku committed rGcb5eb13eafdc: [Attributor] Add helper to change an instruction to `unreachable` inst (authored by uenoku).
[Attributor] Add helper to change an instruction to `unreachable` inst
Thu, Dec 26, 9:47 AM
uenoku closed D71910: [Attributor] Add helper to change an instruction to `unreachable` inst.
Thu, Dec 26, 9:47 AM · Restricted Project
uenoku retitled D71910: [Attributor] Add helper to change an instruction to `unreachable` inst from [Attributor] Add helper to change an instruction to `unrechable` inst to [Attributor] Add helper to change an instruction to `unreachable` inst.
Thu, Dec 26, 9:38 AM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

I create a patch(D71910) for this problem then with that patch, you can use like A.changeToUnreachableAfterManifest(I).

Thu, Dec 26, 9:38 AM · Restricted Project
uenoku added a comment to D71910: [Attributor] Add helper to change an instruction to `unreachable` inst.

This makes sense and LGTM.

FWIW. We have to go over the entire "rewrite after manifest" stuff soon.

Thu, Dec 26, 9:38 AM · Restricted Project
uenoku created D71910: [Attributor] Add helper to change an instruction to `unreachable` inst.
Thu, Dec 26, 9:29 AM · Restricted Project
uenoku added inline comments to D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Thu, Dec 26, 9:10 AM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

So, I tried to make a reduced test case that fails:

define void @fails() {
entry:
  br i1 undef, label %end, label %end

end:
  %phi = phi i32* [ null, %entry ], [ null, %entry ]
  %a = load i32, i32* %phi, align 4
  ret void
}

It's based on the test case IPConstantProp/PR26044.ll, which also fails. The interesting things are:

  1. If we remove the load, it doesn't fail.
  2. If we remove the phi it doesn't fail (that's also true for PR26044.ll).
  3. As noted yesterday, if we remove the changeToUnreachable in AAUndefinedBehavior::manifest(), it doesn't fail (all the test cases basically fail because of this part).
  4. Also, that AAIsDead seems to have a problem with it. My guess is that the fact that we change a branch instruction to unreachable means that there's one less predecessor for the then and else blocks of the branch. If one of these 2 hasn't been converted to unreachable and contains a phi, then we have problems as now the BB has one less predecessor than those listed in the phi.
Thu, Dec 26, 8:41 AM · Restricted Project
uenoku added inline comments to D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Thu, Dec 26, 12:51 AM · Restricted Project

Wed, Dec 25

uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

There was a patch by @uenoku to deal with conditional and the merging of states when we are exploring but I don't see it in-tree and I forgot which one it was.

It was D65593. I forgot too:). It is a good opportunity to rebase. I'll work on.
The idea is that if we know there is UB in both branches, we can say there is UB regardless of a condition value.

Wed, Dec 25, 9:15 AM · Restricted Project
uenoku accepted D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

LGTM

Wed, Dec 25, 3:44 AM · Restricted Project
uenoku added inline comments to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..
Wed, Dec 25, 3:41 AM · Restricted Project

Tue, Dec 24

uenoku committed rG1497a4350e26: [MLIR][NFC] Insert const_cast to avoid warning (authored by uenoku).
[MLIR][NFC] Insert const_cast to avoid warning
Tue, Dec 24, 11:02 PM
uenoku closed D71853: [MLIR][NFC] Insert const_cast to avoid warning.
Tue, Dec 24, 11:01 PM · Restricted Project
uenoku added a comment to D71853: [MLIR][NFC] Insert const_cast to avoid warning.

What is the warning?

llvm-project/mlir/include/mlir/IR/Value.h:112:47: warning: cast from 'const mlir::Value *' to 'mlir::Value *' drops const qualifier [-Wcast-qual]
  Value *operator->() const { return (Value *)this; }

Like this

Tue, Dec 24, 9:48 PM · Restricted Project
uenoku added inline comments to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..
Tue, Dec 24, 9:30 PM · Restricted Project
uenoku committed rG1d5d074aef2a: [Attributor] Reach optimistic fixpoint in AAValueSimplify when the value is… (authored by uenoku).
[Attributor] Reach optimistic fixpoint in AAValueSimplify when the value is…
Tue, Dec 24, 9:22 PM
uenoku closed D71852: [Attributor] Reach optimistic fixpoint in AAValueSimplify when the value is constant or undef.
Tue, Dec 24, 9:22 PM · Restricted Project
uenoku updated the diff for D71852: [Attributor] Reach optimistic fixpoint in AAValueSimplify when the value is constant or undef.

Small fix.

Tue, Dec 24, 9:12 PM · Restricted Project
uenoku added a comment to D71852: [Attributor] Reach optimistic fixpoint in AAValueSimplify when the value is constant or undef.

Sorry, I didn't see your comment at first.

No problem.

AAValueSimplify computes the best simplified value, it is considered "assumed" as long as we cannot prove it is correct, once that happens it is "known". In case of a constant (or undef which should actually be a constant), there is not much to do as it is the most simplified version (in almost all cases), thus we know it is a correct value.

Aha yes. Note that this was my initial interpretation as well, hence why I did not understand why was happening what was happening before this change (e.g. at the end of https://reviews.llvm.org/D71799#1795477).
But then, @uenoku's explanation regarding that "simplified" implies "changed" made me think of a different perspective. All in all, since we agree on a common statement of what AAValueSimplified does, everything's ok. :)

Tue, Dec 24, 8:44 PM · Restricted Project
uenoku updated the diff for D71852: [Attributor] Reach optimistic fixpoint in AAValueSimplify when the value is constant or undef.

Address comment.

Tue, Dec 24, 8:35 PM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

Address comment.

  • Use LazyValueInfo as known information
  • Add test(lvi-*.ll)
Tue, Dec 24, 9:16 AM · Restricted Project
uenoku created D71853: [MLIR][NFC] Insert const_cast to avoid warning.
Tue, Dec 24, 5:46 AM · Restricted Project
uenoku created D71852: [Attributor] Reach optimistic fixpoint in AAValueSimplify when the value is constant or undef.
Tue, Dec 24, 4:05 AM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

It seems to me that for constants or undef, this should be known. Looking at initialize() of AAValueSimplifyFloating, for constants and undef, it indicates a pessimistic fixpoint and I don't understand why.

Tue, Dec 24, 3:56 AM · Restricted Project

Mon, Dec 23

uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

Sorry for my lack of words. I thought you were talking about in updateImpl. It can't happen in updates but can happen once reaches to a fix point.

I am talking about updateImpl(), the code above is inside updateImpl(). It seems true though that if it happens, then a fixpoint has been reached.
Essentially was assumption is that AAValueSimplify seems to return behave weirdly when the value undef (i.e. it returns None while an undef value might be known). So with that,
if it happens, we can deduce that the instruction is UB in updateImpl() and that pretty much solves the previous problems.

Sorry for confusing you. I have missed that the shortcut was introduced(https://github.com/llvm/llvm-project/commit/2dad729f0c7b8665d362baecd8ff52449b26051d). I agree that None and isKnown() means undef.

Mon, Dec 23, 6:02 AM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

Alright, that makes sense!
So, one quick question that I hope will help solve some issues: If !SimplifiedV.hasValue() but ValueSimplifyAA.isKnown(), then it is known that the value is undef?

It can't happen but it is semantically correct.

It happens though :) Unless I messed up something. It happens with e.g. this code:

define i1 @ret_undef() {
  ret i1 undef
}

define void @cond_br() {
  %cond = call i1 @ret_undef()
  br i1 %cond, label %t, label %e
t:
  ret void
e:
  ret void
}

And in the Attributor:

if (!SimplifiedV.hasValue()) {
  if (ValueSimplifyAA.isKnown())
    dbgs() << "IS IT UNDEF?\n";
  ...
}

I see the message. Sorry btw that I don't know exactly how AAValueSimplify works. When I started this patch, I assumed it was in everyone's best interest
to not spend time in it right now, so I'm guessing from looking small pieces of its code.

Sorry for my lack of words. I thought you were talking about in updateImpl. It can't happen in updates but can happen once reaches to a fix point.

Mon, Dec 23, 1:47 AM · Restricted Project

Sun, Dec 22

uenoku added a reviewer for D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value.: uenoku.
Sun, Dec 22, 10:52 PM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

I haven't read all of the discussion so it might as well be possible you converged on this already but I'll say it anyway:

Assumed information can used other assumed information, known information only known information.
You can make AAUndefBehavior track assumed information instead of known information but then we need to look at the not yet known facts in every updateImpl iteration again to make sure the assumed status is still justified.

Alright, that makes sense!
So, one quick question that I hope will help solve some issues: If !SimplifiedV.hasValue() but ValueSimplifyAA.isKnown(), then it is known that the value is undef?

Sun, Dec 22, 8:14 PM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..
if (!SimplifiedV.hasValue()) {
  // No value yet, we can assume any value: assume this is undef BUT
  // this is not _known_ so we don't put in the known set.
} else {
  These are also assumption. You can't use these as known
  if (undef) {
    // insert in KnownUB 
  } else {
    // insert in NoUB.
  }
}
Sun, Dec 22, 10:40 AM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

I think you can't use assumption (getAssumedSimplifiedValue) for the known information. You need to use only known information.

Sun, Dec 22, 10:21 AM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

I agree but I assumed wrongly apparently. You see, with "we can assume it is undef" I thought that I should also add it to the UBInsts set. Up to that point, if I were to do that, it would be wrong since
if something is added to UBInsts, it would never be checked again. But apparently Johannes did not mean this.

I got the point! I missed that UB is intended to be used for liveness. Sorry about that. I'll rethink the problem. But it seems for me that current implementation regards *assumed* UBInsts as *known* UBInsts. Because once I is assumed to have UB, we never visit I. I guess this will cause invalid deduction.

Sun, Dec 22, 9:50 AM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

Note that while this is what makes sense to me, Johannes told me that if SimplifiedV gives None (i.e. it doesn't have value), then we can assume
that it is undef but I don't know why this is true.

Sun, Dec 22, 8:48 AM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

In the current patch, I think an instruction might be inserted to both UBInsts and NoUBInsts in some cases when AAValueSimplify changes its assumption.

Yes, I forgot to add the check that guards this the previous patches (check the first if in InspectMemAccessInstForUB).

In my understanding, the idea of this deduction is
" We assume br instruction causes UB. If you can prove that the instruction *doesn't* cause UB, we remove that assumption".

Yes exactly. Well, my initial assumption was this:

SimplifiedV = ...;
if (!SimplifiedV.hasValue())
  ... // Do nothing for now, no value yet.
else {
  Val = SimplifiedV.getValue();
  if (Val is undef)
    UBInsts.insert;
  else
    NoUBInsts.insert;
}

Then, now that I see that again apparently I got confused somewhere so let me change this quickly. :P
Is this what you had in mind ?

So I think we don't need to have both UBInsts and NoUBInsts because if an instruction is not in NoUBInsts then it is assumed to cause UB.
( You can find that AAISDeadFunction is similar. If BB is not in AssumedLiveBlocks, then it is assumed to be Dead`).

As I noted above, these 2 sets should have no common elements. With that, having both of them just makes some things easier
(like stats, looping over UB instructions in manifest, checking if an instruction is UB).

bool isAssumedToCauseUB(I*){
   return !NoUBInsts.count(I);
}
...
SimplifiedV = ...;
if (!SimplifiedV.hasValue())
  // Do nothing. Assumption holds (Because the value might be simplified to `undef`)
else {
  Val = SimplifiedV.getValue();
  if (Val is undef)
    // Do nothing. Assumption holds.
  else
    NoUBInsts.insert;
}
Sun, Dec 22, 8:02 AM · Restricted Project
uenoku added a comment to D71799: [Attributor] AAUndefinedBehavior: Check for branches on undef value..

In the current patch, I think an instruction might be inserted to both UBInsts and NoUBInsts in some cases when AAValueSimplify changes its assumption.

Sun, Dec 22, 7:21 AM · Restricted Project
uenoku accepted D68765: [Attributor] Function signature rewrite infrastructure.

LGTM

Sun, Dec 22, 6:09 AM · Restricted Project

Sat, Dec 21

uenoku added inline comments to D68765: [Attributor] Function signature rewrite infrastructure.
Sat, Dec 21, 8:28 AM · Restricted Project
uenoku added inline comments to D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Sat, Dec 21, 8:22 AM · Restricted Project
uenoku added inline comments to D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Sat, Dec 21, 8:19 AM · Restricted Project
uenoku added inline comments to D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Sat, Dec 21, 8:19 AM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

Address comments.

Sat, Dec 21, 8:13 AM · Restricted Project

Dec 18 2019

uenoku retitled D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range from [Attributor] AAValueConstantRange: Value range analysis using constant range to [Attributor][WIP] AAValueConstantRange: Value range analysis using constant range.
Dec 18 2019, 8:43 AM · Restricted Project
uenoku updated the summary of D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Dec 18 2019, 8:04 AM · Restricted Project
uenoku retitled D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range from [Attributor][WIP] AAValueConstantRange: Value range analysis using constant range to [Attributor] AAValueConstantRange: Value range analysis using constant range.
Dec 18 2019, 8:04 AM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
  • Add test
  • Use SCEV when the value is phi and defined with circular.
  • Create AA for CmpInst.
Dec 18 2019, 7:57 AM · Restricted Project

Dec 17 2019

uenoku updated the summary of D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Dec 17 2019, 12:12 PM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

Remove unused function

Dec 17 2019, 12:07 PM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

Add comment

Dec 17 2019, 12:01 PM · Restricted Project
uenoku accepted D68008: [Attributor] Use abstract call sites to determine associated arguments.

LGTM

Dec 17 2019, 11:15 AM · Restricted Project
uenoku updated the summary of D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Dec 17 2019, 10:54 AM · Restricted Project
uenoku updated the diff for D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.

Fix typo.

Dec 17 2019, 10:54 AM · Restricted Project
uenoku created D71620: [Attributor] AAValueConstantRange: Value range analysis using constant range.
Dec 17 2019, 10:46 AM · Restricted Project

Dec 13 2019

uenoku accepted D68852: [Attributor] Pointer privatization attribute (argument promotion).

LGTM from my side but please make sure that it passes test-suite.

Dec 13 2019, 3:50 AM · Restricted Project

Dec 12 2019

uenoku added a comment to D68852: [Attributor] Pointer privatization attribute (argument promotion).

Looks generally fine.
I couldn't imagine what is Pointer privatization at first hand. Could you add an example result of Pointer privatization? Like,

int f(int* ptr){
 ...
}
=>
int f(int p){
 int* ptr = &p;
 ...
}

And I guess the current implementation always does privatization if possible. I think the cost may increase in some cases. What do you think about?

Dec 12 2019, 6:58 AM · Restricted Project
uenoku committed rG4ecf25545c3b: [Attributor][NFC] Fix comments and unnecessary comma (authored by uenoku).
[Attributor][NFC] Fix comments and unnecessary comma
Dec 12 2019, 5:47 AM
uenoku committed rG827bade262ba: [Attributor] [NFC] Use `checkForAllUses` helpr in `AAHeapToStackImpl… (authored by uenoku).
[Attributor] [NFC] Use `checkForAllUses` helpr in `AAHeapToStackImpl…
Dec 12 2019, 5:38 AM
uenoku committed rG63599bd07274: [Attributor][NFC] Refactoring `AANoFreeArgument::updateImpl` (authored by uenoku).
[Attributor][NFC] Refactoring `AANoFreeArgument::updateImpl`
Dec 12 2019, 5:38 AM
uenoku closed D71352: [Attributor] [NFC] Use `checkForAllUses` helpr in `AAHeapToStackImpl::updateImpl`.
Dec 12 2019, 5:37 AM · Restricted Project
uenoku closed D71349: [Attributor][NFC] Refactoring `AANoFreeArgument::updateImpl`.
Dec 12 2019, 5:37 AM · Restricted Project

Dec 11 2019

uenoku added a comment to D70767: [Attributor] Add an Attributor CG-SCC pass.

I think changes for replaceAllUsesWith are not related to CG-SCC pass. For that part, LGTM. Could you split the patch?

Dec 11 2019, 6:27 AM · Restricted Project
uenoku added inline comments to D71349: [Attributor][NFC] Refactoring `AANoFreeArgument::updateImpl`.
Dec 11 2019, 6:18 AM · Restricted Project
uenoku created D71352: [Attributor] [NFC] Use `checkForAllUses` helpr in `AAHeapToStackImpl::updateImpl`.
Dec 11 2019, 6:17 AM · Restricted Project
uenoku created D71349: [Attributor][NFC] Refactoring `AANoFreeArgument::updateImpl`.
Dec 11 2019, 5:34 AM · Restricted Project

Dec 2 2019

uenoku committed rG96552036e307: [Attributor] Copy or port test cases related to Attributor to` Attributor` test… (authored by uenoku).
[Attributor] Copy or port test cases related to Attributor to` Attributor` test…
Dec 2 2019, 7:40 AM
uenoku closed D70843: [Attributor] Copy or port test cases related to Attributor to` Attributor` test folder.
Dec 2 2019, 7:40 AM · Restricted Project