Page MenuHomePhabricator
Feed Advanced Search

Sun, May 10

uenoku accepted D78729: [Attributor] Merge the query set into AbstractAttribute.
Sun, May 10, 10:38 AM · Restricted Project
uenoku requested changes to D78729: [Attributor] Merge the query set into AbstractAttribute.

Looks good to me.

Sun, May 10, 10:38 AM · Restricted Project
uenoku accepted D79680: [Attributor] Fix for a crash on RAUW when rewriting function signature.

Looks reasonable to me.

Sun, May 10, 10:06 AM · Restricted Project

Apr 23 2020

uenoku accepted D78719: [Attributor] Inititialize "value attributes" w/ must-be-executed-context info.

LGTM

Apr 23 2020, 11:21 AM · Restricted Project

Mar 29 2020

uenoku accepted D76870: [Attributor] Use the proper context instruction in genericValueTraversal.

LGTM

Mar 29 2020, 7:59 AM · Restricted Project

Mar 28 2020

uenoku accepted D76918: [NFC] Remove obsolete checks followed by fix of isGuaranteedToTransferExecutionToSuccessor.
Mar 28 2020, 8:04 AM · Restricted Project

Mar 27 2020

uenoku added a comment to D76918: [NFC] Remove obsolete checks followed by fix of isGuaranteedToTransferExecutionToSuccessor.

This makes sense to me.

Mar 27 2020, 5:56 AM · Restricted Project

Mar 26 2020

uenoku added a comment to D76674: [Attributor] Derive better alignment for accessed pointers.

Why can't we use ABI info without known access?
I mean, is it possible to use ABI info in initialize?

See my previous comment.
If we decide that pointer has ABI alignment from the get go,
then we will immediately update every underaligned load/store to no longer be underaligned,
which makes no sense. Unless i'm horribly mistaken, just because we said that %z is i32* or i512*,
it doesn't mean it is UB for it to be aligned to a single byte (& 0b1 == 1),
it is the access to such misaligned pointer that is UB.

Mar 26 2020, 11:25 AM · Restricted Project
uenoku added a comment to D76674: [Attributor] Derive better alignment for accessed pointers.

Why can't we use ABI info without known access?
I mean, is it possible to use ABI info in initialize?

Mar 26 2020, 10:18 AM · Restricted Project

Mar 25 2020

uenoku added inline comments to D76588: [Attributor] Unify testing (=updates,prefixes,run configurations,...).
Mar 25 2020, 5:54 AM · Restricted Project
uenoku added a comment to D76673: [Attributor][FIX] Prevent alignment breakage wrt. must-tail calls.

Good point. It is about:
Attribute::StructRet, Attribute::ByVal, Attribute::InAlloca, Attribute::InReg, Attribute::Returned, Attribute::SwiftSelf, Attribute::SwiftError, Attribute::Alignment

Seems reasonable but I'm not sure why we need to care about returned.

Mar 25 2020, 5:22 AM · Restricted Project

Mar 23 2020

uenoku added a comment to D76175: [Attributor][NFC] Refactorings and typos in doc.

LGTM but it is not fixing the typo rather refactoring :)

Mar 23 2020, 9:48 AM · Restricted Project

Mar 21 2020

uenoku added inline comments to D76208: [Attributor] Use AAValueConstantRange to infer dereferencability..
Mar 21 2020, 8:01 AM · Restricted Project
uenoku added inline comments to D76208: [Attributor] Use AAValueConstantRange to infer dereferencability..
Mar 21 2020, 8:01 AM · Restricted Project
uenoku added inline comments to D76208: [Attributor] Use AAValueConstantRange to infer dereferencability..
Mar 21 2020, 4:47 AM · Restricted Project

Mar 20 2020

uenoku accepted D76378: [Attributor] Make use of analysis in the MustBeExecutedExplorer.
Mar 20 2020, 11:55 AM · Restricted Project

Mar 19 2020

uenoku requested changes to D76378: [Attributor] Make use of analysis in the MustBeExecutedExplorer.
Mar 19 2020, 4:27 PM · Restricted Project
uenoku added inline comments to D76210: [Attributor] AAReachability : use isPotentiallyReachable in isKnownReachable.
Mar 19 2020, 4:17 AM · Restricted Project
uenoku accepted D76378: [Attributor] Make use of analysis in the MustBeExecutedExplorer.

LGTM

Mar 19 2020, 12:31 AM · Restricted Project
uenoku added a comment to D76378: [Attributor] Make use of analysis in the MustBeExecutedExplorer.

test?

Mar 19 2020, 12:30 AM · Restricted Project

Mar 18 2020

uenoku added a comment to D76378: [Attributor] Make use of analysis in the MustBeExecutedExplorer.

I think Stefan is correct. AnalysisGetter provides such functionality.

Mar 18 2020, 10:15 PM · Restricted Project

Mar 17 2020

uenoku added inline comments to D76210: [Attributor] AAReachability : use isPotentiallyReachable in isKnownReachable.
Mar 17 2020, 11:25 PM · Restricted Project

Mar 16 2020

uenoku added a comment to D76210: [Attributor] AAReachability : use isPotentiallyReachable in isKnownReachable.
void use(int *);
__attribute__((noinline)) static void f1(int * restrict p, int c1, int c2) {
  if (c1) {
    use(p);
  }
  if (!c2) {
    use(p);
  }
}
void f2(int * restrict p, int c) { f1(p, c, c); }

Could you add this example to test?
In this case, c1 and c2 are always same. Because of flow sensitivity, the first callsite is not reachable to the second callsite. So %p is noalias at both callsites. It can't be deduced with isPotentiallyReachable so please add FIXME tag.

Mar 16 2020, 1:05 AM · Restricted Project

Mar 15 2020

uenoku added a comment to D76210: [Attributor] AAReachability : use isPotentiallyReachable in isKnownReachable.

Please upload full context of the diff (diff -U999999)

Mar 15 2020, 10:51 PM · Restricted Project
uenoku added a reviewer for D76208: [Attributor] Use AAValueConstantRange to infer dereferencability.: baziotis.
Mar 15 2020, 10:18 PM · Restricted Project
uenoku added a reviewer for D76210: [Attributor] AAReachability : use isPotentiallyReachable in isKnownReachable: baziotis.
Mar 15 2020, 10:18 PM · Restricted Project
uenoku added a comment to D76210: [Attributor] AAReachability : use isPotentiallyReachable in isKnownReachable.

Thank you for working on this! Please add isKnownReachable change.

Mar 15 2020, 10:18 PM · Restricted Project
uenoku added a comment to D76208: [Attributor] Use AAValueConstantRange to infer dereferencability..

Thank you for working on this!!

Mar 15 2020, 10:18 PM · Restricted Project

Mar 14 2020

uenoku accepted D74888: [Attributor] Use knowledge retained in llvm.assume (operand bundles).

LGTM

Mar 14 2020, 1:33 AM · Restricted Project

Mar 13 2020

uenoku added a comment to D74691: [Attributor] Detect possibly unbounded cycles in functions.

You don't have to care about the failure if the failure doesn't occur multiple times.
Please see https://lists.llvm.org/pipermail/llvm-dev/2019-November/136710.html

I think a better way to put it is that you don't have to care about the failure if you did not cause it (e.g. you might not get multiple emails if other bots were broken before)

Mar 13 2020, 11:17 AM · Restricted Project
uenoku added a comment to D74691: [Attributor] Detect possibly unbounded cycles in functions.

You don't have to care about the failure if the failure doesn't occur multiple times.
Please see https://lists.llvm.org/pipermail/llvm-dev/2019-November/136710.html

Mar 13 2020, 10:44 AM · Restricted Project
uenoku accepted D74691: [Attributor] Detect possibly unbounded cycles in functions.

LGTM

Mar 13 2020, 4:24 AM · Restricted Project
uenoku added a comment to D71617: [Attributor] Improve noalias preservation using reachability.

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

Mar 13 2020, 2:58 AM · Restricted Project
uenoku accepted D71617: [Attributor] Improve noalias preservation using reachability.

LGTM

Mar 13 2020, 1:33 AM · Restricted Project

Mar 12 2020

uenoku committed rGd9bf79f4e995: [Attributor][FIX] Add a missing dependence track in noalias deduction (authored by uenoku).
[Attributor][FIX] Add a missing dependence track in noalias deduction
Mar 12 2020, 8:42 AM
uenoku added a comment to D71617: [Attributor] Improve noalias preservation using reachability.

Please guide on why nonull.ll shows additional noalias propagation. I see that the caller doesn't have noalias attribute but it has derived it.

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)

Mar 12 2020, 8:40 AM · Restricted Project
uenoku planned changes to D75923: [Attributor] Deduction based on recursive path exploration.

This patch traverses the same context multiple times so the cost might get huge.
I'll create something like a cache.

Mar 12 2020, 3:46 AM · Restricted Project
uenoku added inline comments to D75923: [Attributor] Deduction based on recursive path exploration.
Mar 12 2020, 3:46 AM · Restricted Project

Mar 11 2020

uenoku abandoned D75924: [Attributor] AANoCapture: Regard a comparison to null as nocapture.

I have misunderstood how CaptureTracker works. AANoCapture already has this functionality :) So I'd close it.
But I have thought some of FIXME in the test seems wrong.

Mar 11 2020, 1:35 AM · Restricted Project

Mar 10 2020

uenoku added inline comments to D74691: [Attributor] Detect possibly unbounded cycles in functions.
Mar 10 2020, 9:12 AM · Restricted Project
uenoku added a comment to D75924: [Attributor] AANoCapture: Regard a comparison to null as nocapture.

I have missed to check the dereferenceability of the pointer. I'll fix it later.
So now the tests are broken.

Mar 10 2020, 8:39 AM · Restricted Project
uenoku created D75924: [Attributor] AANoCapture: Regard a comparison to null as nocapture.
Mar 10 2020, 8:39 AM · Restricted Project
uenoku created D75923: [Attributor] Deduction based on recursive path exploration.
Mar 10 2020, 7:32 AM · Restricted Project

Mar 9 2020

uenoku added inline comments to D74691: [Attributor] Detect possibly unbounded cycles in functions.
Mar 9 2020, 9:09 AM · Restricted Project
uenoku added a comment to D71617: [Attributor] Improve noalias preservation using reachability.

Please use code block.

Mar 9 2020, 8:35 AM · Restricted Project

Mar 8 2020

uenoku committed rGbdcbdb484829: [Attributor] Deduction based on path exploration (authored by uenoku).
[Attributor] Deduction based on path exploration
Mar 8 2020, 10:55 PM
uenoku closed D65593: [Attributor] Deduction based on path exploration.
Mar 8 2020, 10:55 PM · Restricted Project

Mar 7 2020

uenoku added a comment to D65593: [Attributor] Deduction based on path exploration.

I have not convinced myself that this covers the recursive case properly, maybe that was never the intend though. Can we have a test like this:

Mar 7 2020, 1:38 AM · Restricted Project
uenoku updated the diff for D65593: [Attributor] Deduction based on path exploration.

Fix comment and add test.

Mar 7 2020, 1:38 AM · Restricted Project

Mar 6 2020

uenoku added inline comments to D75590: [Attributor] IPO across definition boundary of a function marked alwaysinline.
Mar 6 2020, 12:35 AM · Restricted Project

Mar 4 2020

uenoku added a comment to D75433: [MLIR] Add llvm.switch.

As I see the discussion in the forum, it seems best to create a basic block for each case. I'll implement so.

Mar 4 2020, 5:06 AM
uenoku added inline comments to D75590: [Attributor] IPO across definition boundary of a function marked alwaysinline.
Mar 4 2020, 5:06 AM · Restricted Project

Mar 2 2020

uenoku added a comment to D75433: [MLIR] Add llvm.switch.

We can impose a similar restriction on switch in the LLVM dialect and require whoever constructs the IR to deal with it. This may be suboptimal from the usability standpoint, but so is automagically inserting dummy blocks in the translation. We've had a similar discussion in the indirectbr patch, inconclusive as far as I can tell. Let's bring this to the discussion form.

Ok, that seems fine.

Mar 2 2020, 5:02 AM
uenoku added a comment to D75433: [MLIR] Add llvm.switch.

@rriddle @ftynse Thank you for the comments :)

Thanks for the patch!

Currently, successors are not allowed to have block arguments because we can't directly translate block arguments into phi node.

Could you elaborate on this? We have logic that translates branch arguments into phi nodes as a post-processing step after all blocks, it should be sufficient to modify getPHISourceValue to handle switch in addition to branches.

Mar 2 2020, 2:42 AM

Mar 1 2020

uenoku created D75433: [MLIR] Add llvm.switch.
Mar 1 2020, 9:17 PM

Feb 27 2020

uenoku updated the diff for D65593: [Attributor] Deduction based on path exploration.

Simplify implementation.

Feb 27 2020, 7:03 PM · Restricted Project
uenoku added inline comments to D65593: [Attributor] Deduction based on path exploration.
Feb 27 2020, 7:03 PM · Restricted Project

Feb 26 2020

uenoku added a comment to D74691: [Attributor] Detect possibly unbounded cycles in functions.

Could you make sure that you are using a new pass manager? (It means to use ./opt -passes=attributor .. but not ./opt -attributor ..)
If you are using an old pass manager, you might not get LoopInfo or other analysis.

Feb 26 2020, 2:42 AM · Restricted Project
uenoku added inline comments to D65593: [Attributor] Deduction based on path exploration.
Feb 26 2020, 2:22 AM · Restricted Project
uenoku added inline comments to D65593: [Attributor] Deduction based on path exploration.
Feb 26 2020, 1:18 AM · Restricted Project
uenoku updated the diff for D65593: [Attributor] Deduction based on path exploration.

Address comments

Feb 26 2020, 1:10 AM · Restricted Project

Feb 25 2020

uenoku updated the diff for D65593: [Attributor] Deduction based on path exploration.

Rebased. I simply use AbstractState to accumulate the known information.

Feb 25 2020, 4:33 AM · Restricted Project

Feb 24 2020

uenoku committed rG2c0edbf19c1b: [Attributor] Use AssumptionCache in AANonNullFloating::initialize (authored by uenoku).
[Attributor] Use AssumptionCache in AANonNullFloating::initialize
Feb 24 2020, 8:13 PM
uenoku added inline comments to D74888: [Attributor] Use knowledge retained in llvm.assume (operand bundles).
Feb 24 2020, 3:15 AM · Restricted Project

Feb 21 2020

uenoku resigned from D74994: [LTO] Rename legacy LTO files. NFC..
Feb 21 2020, 6:27 PM · Restricted Project
uenoku added inline comments to D74888: [Attributor] Use knowledge retained in llvm.assume (operand bundles).
Feb 21 2020, 3:14 AM · Restricted Project

Feb 19 2020

uenoku committed rGe253cdda35eb: [MustExecute] Add backward exploration for must-be-executed-context (authored by uenoku).
[MustExecute] Add backward exploration for must-be-executed-context
Feb 19 2020, 9:51 PM
uenoku closed D74817: [MustExecute] Add backward exploration for must-be-executed-context.
Feb 19 2020, 9:51 PM · Restricted Project
uenoku updated the diff for D74817: [MustExecute] Add backward exploration for must-be-executed-context.

Address comments

Feb 19 2020, 7:29 PM · Restricted Project
uenoku created D74817: [MustExecute] Add backward exploration for must-be-executed-context.
Feb 19 2020, 12:13 AM · Restricted Project

Feb 17 2020

uenoku added inline comments to D73428: [Attributor] Improve `noalias` deduction based on memory information.
Feb 17 2020, 3:50 AM · Restricted Project
uenoku added a comment to D73428: [Attributor] Improve `noalias` deduction based on memory information.

And I have a question.

define i32 @f1(i32* %p, i32* %q){
entry:
  %0 = load i32, i32* %q
  %1 = load i32, i32* %p
  %add = add nsw i32 %1, %0
  ret i32 %add
}
Feb 17 2020, 3:41 AM · Restricted Project
uenoku added inline comments to D73428: [Attributor] Improve `noalias` deduction based on memory information.
Feb 17 2020, 3:05 AM · Restricted Project

Feb 16 2020

uenoku added a comment to D74691: [Attributor] Detect possibly unbounded cycles in functions.

I'm not sure whether we can say if all the loops given by LoopInfo have a max trip count and all the callees are willreturn, then we can guarantee the termination of that function.

We can not. But if all cycles in the CFG are loops recognized by loop info and they have a max trip count we are good (in this part), I think.

How can we confirm all cycles in the CFG are recognized actually by loop info? Is there a simple way?

What @omarahmed does here should work (with the fixes I mentioned). As before, we identify all cycles via the depth-first search and the visited set. If a cycles is found we did bail before but now we ask LI & SE instead. If they say we found a proper loop header of a loop with a bounded trip count we can ignore that cycles and continue exploring. Do you think there is a problem with that logic?

I might misunderstand the logic. This seems fine. I also think @baziotis's idea works well.

Feb 16 2020, 9:42 PM · Restricted Project
uenoku added a comment to D74691: [Attributor] Detect possibly unbounded cycles in functions.

I'm not sure whether we can say if all the loops given by LoopInfo have a max trip count and all the callees are willreturn, then we can guarantee the termination of that function.

We can not. But if all cycles in the CFG are loops recognized by loop info and they have a max trip count we are good (in this part), I think.

How can we say all cycles in the CFG are recognized actually by loop info? Is there a simple way?

Feb 16 2020, 11:38 AM · Restricted Project
uenoku added a comment to D74691: [Attributor] Detect possibly unbounded cycles in functions.

I'm not sure whether we can say if all the loops given by LoopInfo have a max trip count, then we can guarantee the termination of that function.
Aren't there other factors causing non-terminating execution?

Feb 16 2020, 11:23 AM · Restricted Project

Feb 14 2020

uenoku accepted D73527: [Attributor] Collect memory accesses with their respective kind and location.

LGTM

Feb 14 2020, 6:28 PM · Restricted Project

Feb 13 2020

uenoku accepted D73426: [Attributor] Derive memory location attributes (argmemonly, ...).

I think a state without NO_UNKOWN_MEM is semantically identical to a pessimistic fixpoint, right?

In this patch probably true. With D73527 users can iterate over the "unknown" accesses and determine their original on their own. Once we give up, we do not guarantee all accesses are tracked.

Feb 13 2020, 11:20 PM · Restricted Project
uenoku added a comment to D73426: [Attributor] Derive memory location attributes (argmemonly, ...).

Sorry for the delay. I have just completed my bachelor's course so I can take enough time for development.

Feb 13 2020, 10:34 PM · Restricted Project

Feb 2 2020

uenoku added a comment to D73426: [Attributor] Derive memory location attributes (argmemonly, ...).

Are there tests for inaccessiblememonly or inaccessiblemem_or_argmemonly?

Feb 2 2020, 2:58 AM · Restricted Project

Jan 14 2020

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

Add the test.

Jan 14 2020, 5:07 AM · Restricted Project

Jan 4 2020

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.

Jan 4 2020, 12:06 AM · Restricted Project

Jan 3 2020

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.

Jan 3 2020, 1:13 AM · Restricted Project

Jan 2 2020

uenoku committed rG5fc02dc0a7b6: Revert "[Attributor] AAValueConstantRange: Value range analysis using constant… (authored by uenoku).
Revert "[Attributor] AAValueConstantRange: Value range analysis using constant…
Jan 2 2020, 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….
Jan 2 2020, 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.

Jan 2 2020, 6:06 PM · Restricted Project

Jan 1 2020

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

LGTM

Jan 1 2020, 12:31 PM · Restricted Project

Dec 31 2019

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

Remove outdated todos.

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

Minor update.

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

LGTM from me.

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

Dec 30 2019

uenoku added inline comments to D72017: [Attributor] AANoRecurse check all call sites for `norecurse`.
Dec 30 2019, 11:57 PM · Restricted Project
uenoku added inline comments to D72017: [Attributor] AANoRecurse check all call sites for `norecurse`.
Dec 30 2019, 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.

Dec 30 2019, 11:47 AM · Restricted Project
uenoku added inline comments to D71960: [Attributor] AAUndefinedBehavior: Use AAValueSimplify in memory accessing instructions..
Dec 30 2019, 9:19 AM · Restricted Project
uenoku added inline comments to D71960: [Attributor] AAUndefinedBehavior: Use AAValueSimplify in memory accessing instructions..
Dec 30 2019, 8:03 AM · Restricted Project