anna (Anna Thomas)
User

Projects

User does not belong to any projects.

User Details

User Since
Mar 30 2016, 11:13 AM (129 w, 2 d)

Recent Activity

Today

anna added a comment to D52362: [CloneFunction] Simplify previously unsimplifiable instructions.
Fri, Sep 21, 1:54 PM
anna added a comment to D52327: [Loop Vectorizer] Abandon vectorization when no integer IV found.

Why do we need an integer induction variable? If one doesn't exist, it should be straightforward to create one.

Is there a practical need (i.e., beyond academic interest) to vectorize such code? Examples?

Fri, Sep 21, 1:42 PM
anna created D52362: [CloneFunction] Simplify previously unsimplifiable instructions.
Fri, Sep 21, 8:24 AM

Tue, Sep 18

anna updated the diff for D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

addressed review comments.

Tue, Sep 18, 1:40 PM
anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

Hi Ayal, thanks for your detailed review!

Best allow only a single store to an invariant address for now; until we're sure the last one to store is always identified correctly.

I've updated the patch to restrict to this case for now (diff coming up soon). Generally, if we have multiple stores to an invariant address, it might be canonicalized by InstCombine. So, this may not be as inhibiting as it sounds. Keeping this restriction and allowing "variant stores to invariant addresses" seems like a logical next step once this lands.

Tue, Sep 18, 12:17 PM

Thu, Sep 13

anna added a comment to D51964: [InstCombine] Fold (xor (min/max X, Y), -1) -> (max/min ~X, ~Y) when X and Y are freely invertible..

This whole patch does fix the infinite loop from PR38915, but it requires the whole patch and not just the change in InstCombineSelect.cpp

Thu, Sep 13, 8:33 AM

Mon, Sep 10

anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

ping

Mon, Sep 10, 7:18 AM
anna updated the diff for D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

rebased over D51313.

Mon, Sep 10, 7:18 AM
anna added inline comments to D51313: [LV] Fix code gen for conditionally executed uniform loads.
Mon, Sep 10, 7:07 AM

Thu, Sep 6

anna updated the diff for D51313: [LV] Fix code gen for conditionally executed uniform loads.

addressed review comment.

Thu, Sep 6, 12:06 PM
anna added inline comments to D51313: [LV] Fix code gen for conditionally executed uniform loads.
Thu, Sep 6, 10:49 AM

Wed, Sep 5

anna added inline comments to D51486: Add check to Latch's terminator in UnrollRuntimeLoopRemainder.
Wed, Sep 5, 12:39 PM
anna updated the diff for D51313: [LV] Fix code gen for conditionally executed uniform loads.

addressed review comments.

Wed, Sep 5, 12:26 PM
anna added inline comments to D51313: [LV] Fix code gen for conditionally executed uniform loads.
Wed, Sep 5, 12:23 PM

Tue, Sep 4

anna added a comment to D51639: [LV] Fix PR38786 - consider first order recurrence phis non-uniform.

I think this is ready. Would someone like to commit it?

Tue, Sep 4, 2:03 PM
anna added inline comments to D51639: [LV] Fix PR38786 - consider first order recurrence phis non-uniform.
Tue, Sep 4, 9:58 AM
anna accepted D51639: [LV] Fix PR38786 - consider first order recurrence phis non-uniform.

LGTM. thanks for the fix!

Tue, Sep 4, 9:03 AM
anna accepted D50730: [AST] Generalize argument specific aliasing.

LGTM.

Tue, Sep 4, 8:15 AM
anna added a comment to D51313: [LV] Fix code gen for conditionally executed uniform loads.

ping

Tue, Sep 4, 8:01 AM

Fri, Aug 31

anna added a comment to D51486: Add check to Latch's terminator in UnrollRuntimeLoopRemainder.

Please upload patch with complete context. Could you also add a test case show casing your problem (which you've described earlier): Just a loop with unconditional latch terminator and run through runtime-unroll.

Fri, Aug 31, 5:53 AM

Thu, Aug 30

anna requested review of D51313: [LV] Fix code gen for conditionally executed uniform loads.
Thu, Aug 30, 7:58 AM
anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

This patch now only vectorizes invariant values stored into invariant addresses. It also correctly handles conditionally executed stores (fixed bug for scatter code generation in AVX512).

Thu, Aug 30, 7:52 AM
anna updated the diff for D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

added test for conditional uniform store for AVX512. Rebased over fix in D51313.

Thu, Aug 30, 7:51 AM

Wed, Aug 29

anna added a comment to D51313: [LV] Fix code gen for conditionally executed uniform loads.

To state what's fixed in latest patch:

  1. Uniform loads on architectures with gather support will NOT be scalarized. In particular, both the cost model ( and the actual code gen in setCostBasedWideningDecision) and the codeGen for replication and widening recipes do the respective operations for widening decision != CM_GatherScatter. 1.1 For the recipes which are handled after the widening decision is set, we use the isScalarWithPredication(I, VF) form which is added in the patch.
Wed, Aug 29, 11:50 AM
anna updated the diff for D51313: [LV] Fix code gen for conditionally executed uniform loads.

addressed review comments - we make sure that the vectorization also uses the cost decision of gather/scatter
instead of scalarizing.
Also, handles the original bug of generating incorrect code for conditional uniform loads.

Wed, Aug 29, 11:23 AM
anna added inline comments to D51313: [LV] Fix code gen for conditionally executed uniform loads.
Wed, Aug 29, 8:23 AM

Tue, Aug 28

anna added inline comments to D51313: [LV] Fix code gen for conditionally executed uniform loads.
Tue, Aug 28, 7:02 AM

Mon, Aug 27

anna created D51313: [LV] Fix code gen for conditionally executed uniform loads.
Mon, Aug 27, 9:19 AM

Fri, Aug 24

anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

We should also consider doing this, depending on the cost of branch versus masked scatter. For the targets w/o masked scatter, this should be better than masked scatter emulation.

%5 = bitcast <16xi1> %4 to <i16>
%6 = icmp eq <i16> %5, <i16> zero
br <i1> %6 skip fall
fall:
store <i32> %ntrunc, <i32*> %a
br skip
skip:

Yes, that is the improved codegen stated as TODO in the costmodel. Today both the costmodel and the code gen will identify it as a normal predicated store: series of branches and stores. Also, we need to differentiate these 2 cases:

if(b[i] ==k)
 a = ntrunc;

versus

if(b[i] ==k)
  a = ntrunc;
else
  a = m;

The second example should be converted into a vector-select based on b[i] == k and the last element will be extracted out of the vector select and stored into a.
However, if for some reason, it is not converted into a select and just left as 2 predicated stores, it is incorrect to use the same code transformation as we'll do for the first example. For the first example, we see if all values in the conditional is false, and we skip the store. In the second case, we need to store a value, but that value is just decided by the last element of the conditional. Just 2 different forms of predicated stores.

Fri, Aug 24, 1:45 PM
anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

One more interesting thing I noticed while adding predicated invariant stores to X86 (for -mcpu=skylake-avx512), it supports masked scatter for non-unniform stores.
But we need to add support for uniform stores along with this patch. Today, it just generates incorrect code (no predication whatsover).
For other architectures that do not have these masked intrinsics, we just generate the predicated store by doing an extract and branch on each lane (correct but inefficient and will be avoided unless -force-vector-width=X).

In general, self output dependence is fine to vectorize (whether the store address is uniform or random), as long as (masked) scatter (or scatter emulation) happens from lower elements to higher elements.

I don't think the above comment matters for uniform addresses because a uniform address is invariant. This is what the langref states for scatter intrinsic (https://llvm.org/docs/LangRef.html#id1792):

. The data stored in memory is a vector of any integer, floating-point or pointer data type. Each vector element is stored in an arbitrary memory address. Scatter with overlapping addresses is guaranteed to be ordered from least-significant to most-significant element.

The scatter address is not overlapping for the uniform address. It is the exact same address. This is the code that gets generated for uniform stores on skylake with AVX-512 support once I fixed the bug in this patch (the scatter location is the same address and the stored value is also the same, and the mask is the vector of booleans):
pseudo code:

if (b[i] ==k)
  a = ntrunc; <-- uniform store based on condition above.

IR generated:

vector.ph:
  %broadcast.splatinsert5 = insertelement <16 x i32> undef, i32 %k, i32 0
  %broadcast.splat6 = shufflevector <16 x i32> %broadcast.splatinsert5, <16 x i32> undef, <16 x i32> zeroinitializer <-- vector splat of k
  %broadcast.splatinsert9 = insertelement <16 x i32*> undef, i32* %a, i32 0
  %broadcast.splat10 = shufflevector <16 x i32*> %broadcast.splatinsert9, <16 x i32*> undef, <16 x i32> zeroinitializer <-- vector splat of i32* a.
Fri, Aug 24, 12:47 PM
anna planned changes to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

see comment above for masked scatter support.

Fri, Aug 24, 10:26 AM
anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

One more interesting thing I noticed while adding predicated invariant stores to X86 (for -mcpu=skylake-avx512), it supports masked scatter for non-unniform stores.
But we need to add support for uniform stores along with this patch. Today, it just generates incorrect code (no predication whatsover).
For other architectures that do not have these masked intrinsics, we just generate the predicated store by doing an extract and branch on each lane (correct but inefficient and will be avoided unless -force-vector-width=X).

Fri, Aug 24, 10:23 AM
anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

okay, to keep this patch true to the original intent and commit message: I'm going to change it to handle just the store of invariant values to invariant addresses (i.e. no support for OR-operands-are-invariant). It will be admittedly a more conservative patch. The ORE message will also reflect correctly the "variant stores to invariant addresses".

Fri, Aug 24, 7:00 AM

Thu, Aug 23

anna accepted D51181: [LICM] Hoist an invariant_start out of loops if there are no stores executed before it.

LGTM

Thu, Aug 23, 2:02 PM
anna added inline comments to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.
Thu, Aug 23, 1:28 PM
anna added a comment to D50925: [LICM] Hoist stores of invariant values to invariant addresses out of loops.

There are 3 kinds of tests worth adding:

  1. predicated invariant stores, i.e. the block containing the store itself is predicated and not guaranteed to execute (cannot be handled by LICM)

Covered by existing early exit test.

  1. invariant store value is a phi containing invariant incoming values and the phi result depends on an invariant condition (can be handled by LICM. This patch handles?)

Unclear what you mean here.

Added example:

define void @inv_val_store_to_inv_address_conditional_inv(i32* %a, i64 %n, i32* %b, i32 %k) {
entry:
  %ntrunc = trunc i64 %n to i32
  %cmp = icmp eq i32 %ntrunc, %k
  br label %for.body
Thu, Aug 23, 12:45 PM
anna added inline comments to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.
Thu, Aug 23, 12:32 PM
anna updated the diff for D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

Added TODOs for better code gen of predicated uniform store and removing redundant loads and stores left behind during
scalarization of these uniform loads and stores.

Thu, Aug 23, 9:59 AM
anna updated the diff for D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

address review comments (NFC wrt previous diff). Added one test for varying value stored into invariant address.

Thu, Aug 23, 9:39 AM
anna added inline comments to D50925: [LICM] Hoist stores of invariant values to invariant addresses out of loops.
Thu, Aug 23, 9:26 AM
anna added a comment to D50925: [LICM] Hoist stores of invariant values to invariant addresses out of loops.

I'll take a closer look at the patch, but at first glance it looks like some cases of invariant store that's preventing the vectorizer (because LICM wasn't hoisting/sinking the store) may be handled by running LICM before vectorization: testcases in D50665 maybe worth trying here - note that those test cases are running LICM before vectorization.

Thu, Aug 23, 8:54 AM
anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

...

Yes, the stores are scalarized. Identical replicas left as-is. Either passes such as load elimination can remove it, or we can clean it up in LV itself.

  • - by revisiting LoopVectorizationCostModel::collectLoopUniforms()? ;-)

Right now, I just run instcombine after loop vectorization to clean up those unnecessary stores (and test cases make sure there's only one store left). Looks like there are other places in LV which relies on InstCombine as the clean up pass, so it may not be that bad after all? Thoughts?

Yeah, this is a bit embarrassing, but currently invariant loads also get replicated (and cleaned up later), despite trying to avoid doing so by recording IsUniform in VPReplicateRecipe. In general, if it's simpler and more consistent to generate code in a common template and potentially cleanup later, should be ok provided the cost model accounts for it accurately and cleanup is guaranteed, as checked by tests. BTW, LV already has an internal cse(). But in this case, VPlan should reflect the final outcome better, i.e., with a correct IsUniform. This should be taken care of, possibly by a separate patch.

Thu, Aug 23, 8:37 AM
anna added inline comments to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.
Thu, Aug 23, 8:36 AM

Aug 21 2018

anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

...

Yes, the stores are scalarized. Identical replicas left as-is. Either passes such as load elimination can remove it, or we can clean it up in LV itself.

  • - by revisiting LoopVectorizationCostModel::collectLoopUniforms()? ;-)
Aug 21 2018, 11:57 AM
anna added inline comments to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.
Aug 21 2018, 11:53 AM
anna updated the diff for D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

Addressed review comments, updated ORE message and tests, fixed an assertion failure in cost model calculation for uniform store (bug uncovered when running test
under X86 skylake)

Aug 21 2018, 11:50 AM
anna added inline comments to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.
Aug 21 2018, 10:03 AM
anna added a comment to D50778: [LV] Vectorize loops where non-phi instructions used outside loop.

thanks for reviewing these changes Ayal!

Aug 21 2018, 6:17 AM

Aug 20 2018

anna updated the diff for D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

Teach LAA about non-predicated uniform store. Added test case for these cases
to make sure they are not treated as predicated stores.

Aug 20 2018, 11:57 AM
anna added inline comments to D50778: [LV] Vectorize loops where non-phi instructions used outside loop.
Aug 20 2018, 9:11 AM
anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

ping

Aug 20 2018, 8:53 AM
anna updated the diff for D50778: [LV] Vectorize loops where non-phi instructions used outside loop.

Updated LoopVectorizationCostModel::collectLoopUniforms to correctly identify uniforms

Aug 20 2018, 8:51 AM
anna added inline comments to D50778: [LV] Vectorize loops where non-phi instructions used outside loop.
Aug 20 2018, 7:26 AM

Aug 17 2018

anna added a comment to D50644: [WIP] [LAA] Allow runtime checks when strides different but address space does not wrap around.

Hi Anna,

If the distance between the source and the sink is loop invariant, how can these have different strides (unless they are also loop invariant)? Could you give an example?

Thanks,
Silviu

Aug 17 2018, 10:26 AM
anna added a comment to D50644: [WIP] [LAA] Allow runtime checks when strides different but address space does not wrap around.

ping

Aug 17 2018, 6:48 AM
anna retitled D50854: [LICM] Add a diagnostic analysis for identifying alias information from [LICM] Add a diagnostic analysis for identifying alias information of loads within loop to [LICM] Add a diagnostic analysis for identifying alias information.
Aug 17 2018, 6:44 AM
anna updated the diff for D50854: [LICM] Add a diagnostic analysis for identifying alias information.

rebased over ToT.

Aug 17 2018, 6:32 AM

Aug 16 2018

anna accepted D50861: [AST] Mark invariant.starts as being readonly.

LGTM.

Aug 16 2018, 2:17 PM
anna updated the diff for D50854: [LICM] Add a diagnostic analysis for identifying alias information.

addressed review comments. added more tests. Diagnostic analysis used for loads and readonly+argmemonly calls.

Aug 16 2018, 2:11 PM
anna added a comment to D50854: [LICM] Add a diagnostic analysis for identifying alias information.

Detailed comments inline.

A couple of testing notes:

  1. don't the guard tests change output as well? Or has Max's fix for that already landed?

I'd tested to see if changing the default value in this patch caused any other LICM test to fail, none did other than the invariant.start case. So, I guess Max's fix has landed for guards.

Aug 16 2018, 11:37 AM
anna created D50854: [LICM] Add a diagnostic analysis for identifying alias information.
Aug 16 2018, 10:45 AM
anna added inline comments to D50778: [LV] Vectorize loops where non-phi instructions used outside loop.
Aug 16 2018, 9:37 AM
anna updated the diff for D50778: [LV] Vectorize loops where non-phi instructions used outside loop.

addressed review comments - added support for uniform instructions.

Aug 16 2018, 9:35 AM
anna added inline comments to D50778: [LV] Vectorize loops where non-phi instructions used outside loop.
Aug 16 2018, 7:39 AM

Aug 15 2018

anna added inline comments to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.
Aug 15 2018, 12:03 PM
anna updated the diff for D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

added cost model changes for unpredicated invariant stores. The predicated invariant stores will
generate extra stores here and the cost model also (already) considers the cost of predicated stores.
Since the cost model correctly reflects the cost of the (badly) generated predicated stores,
I've added couple of tests to show that invariant predicated stores are handled correctly, but TODOs
for follow on patch for better code gen.

Aug 15 2018, 12:00 PM
anna added inline comments to D50778: [LV] Vectorize loops where non-phi instructions used outside loop.
Aug 15 2018, 11:19 AM
anna created D50778: [LV] Vectorize loops where non-phi instructions used outside loop.
Aug 15 2018, 7:01 AM
anna added a comment to D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.

Hi Ayal, thanks for the comments!

The decision how to vectorize invariant stores also deserves attention: LoopVectorizationCostModel::setCostBasedWideningDecision() considers loads from uniform addresses, but not invariant stores - these may end up being scalarized or becoming a scatter; the former is preferred in this case, as the identical scalarized replicas can later be removed.

Yes, the stores are scalarized. Identical replicas left as-is. Either passes such as load elimination can remove it, or we can clean it up in LV itself.

In any case associated cost estimates should be provided to support overall vectorization costs.

agreed.

Note that vectorizing conditional invariant stores deserves special attention. Unconditional invariant stores are candidates to be sunk out of the loop, preferably before trying to vectorize it.

If we get unconditional invariant stores which haven't been sunk out of the loop and it has reached vectorizer, I think we should let the loop vectorizer vectorize it. Irrespective of what other passes such as LICM should have done with store promotion/sinking. See example in https://bugs.llvm.org/show_bug.cgi?id=38546#c1. Even running through clang++ O3 doesn't sink the invariant store out of loop and that store prevents the vectorization of entire loop.

One approach to vectorize a conditional invariant store is to check if its mask is all false, and if not to perform a single invariant scalar store, for lack of a masked-scalar-store instruction. May be worth distinguishing between uniform and divergent conditions; this check is easier to carry out in the former case.

Thanks, I thought these were automatically handled. Will address in updated patch.

Aug 15 2018, 5:16 AM

Aug 14 2018

anna updated the diff for D50579: [LV] Teach about non header phis that have uses outside the loop.

addressed review comments and simplified code.

Aug 14 2018, 7:23 AM
anna added inline comments to D50579: [LV] Teach about non header phis that have uses outside the loop.
Aug 14 2018, 6:31 AM

Aug 13 2018

anna created D50665: [LV][LAA] Vectorize loop invariant values stored into loop invariant address.
Aug 13 2018, 2:29 PM
anna retitled D50644: [WIP] [LAA] Allow runtime checks when strides different but address space does not wrap around from [LAA] Allow runtime checks when strides different but address space does not wrap around to [WIP] [LAA] Allow runtime checks when strides different but address space does not wrap around.
Aug 13 2018, 11:11 AM
anna created D50644: [WIP] [LAA] Allow runtime checks when strides different but address space does not wrap around.
Aug 13 2018, 10:02 AM
anna accepted D50588: [AST] Cleanup code by using MemoryLocation utility [NFC].

LGTM. My concern was if Loc.AATags was same as getAAMetadata and looking through the code in MemoryLocation::get, AATags is populated using getAAMetadata.

Aug 13 2018, 9:33 AM
anna abandoned D50474: [LV] Vectorize header phis that feed from if-convertable latch phis.

We cannot vectorize predicated reductions where the else part of the predicate is a reset of the reduction val.

Aug 13 2018, 9:05 AM
anna updated the diff for D50579: [LV] Teach about non header phis that have uses outside the loop.

addressed review comments. added more tests.

Aug 13 2018, 8:55 AM
anna added a comment to D50579: [LV] Teach about non header phis that have uses outside the loop.

thanks for the comments Ayal. Have added inline comments. Will address those in upcoming patch.

Aug 13 2018, 6:56 AM
anna added inline comments to D50579: [LV] Teach about non header phis that have uses outside the loop.
Aug 13 2018, 6:55 AM

Aug 10 2018

anna created D50579: [LV] Teach about non header phis that have uses outside the loop.
Aug 10 2018, 12:45 PM
anna added inline comments to D50474: [LV] Vectorize header phis that feed from if-convertable latch phis.
Aug 10 2018, 6:55 AM
anna added inline comments to D50474: [LV] Vectorize header phis that feed from if-convertable latch phis.
Aug 10 2018, 6:33 AM

Aug 9 2018

anna added a comment to D50474: [LV] Vectorize header phis that feed from if-convertable latch phis.

Your patch miscompiles the following:

void f(int n, int *p, int *z) {
int x = 100;
#pragma clang loop vectorize(enable)
for (int i = 0; i < n; ++i) {
if (p[i] > 0) x *= p[i];
else x /= p[i];
z[i]=x;
}
}
typedef void fty(int,int*,int*);
fty*volatile ff=f;
int main() {
  int p[] = {1,-2,3,-4};
  int z[] = {1,2,3,4};
  ff(4, p, z);
  printf("%d %d %d %d\n", z[0], z[1], z[2], z[3]);
}
Aug 9 2018, 3:05 PM
anna added a comment to D50474: [LV] Vectorize header phis that feed from if-convertable latch phis.

fuzz testing this patch through our internal fuzzer shows all tests passed.

Aug 9 2018, 10:24 AM

Aug 8 2018

anna added a reviewer for D50474: [LV] Vectorize header phis that feed from if-convertable latch phis: hfinkel.
Aug 8 2018, 5:47 PM
anna updated the diff for D50474: [LV] Vectorize header phis that feed from if-convertable latch phis.

clang formatted the change and added some comments. NFC wrt previous diff.

Aug 8 2018, 2:10 PM
anna added inline comments to D50474: [LV] Vectorize header phis that feed from if-convertable latch phis.
Aug 8 2018, 1:58 PM
anna created D50474: [LV] Vectorize header phis that feed from if-convertable latch phis.
Aug 8 2018, 1:53 PM

Jun 22 2018

anna accepted D47441: SafepointIRVerifier should ignore dead blocks and dead edges.

LGTM. Artur, could you please land the patch? My llvm repo seems to be having issues. Thanks.

Jun 22 2018, 10:10 AM

Jun 14 2018

anna added a comment to D47441: SafepointIRVerifier should ignore dead blocks and dead edges.

Generally LGTM. pls wait for Artur's comments (if any).

Jun 14 2018, 7:33 AM
anna added inline comments to D47441: SafepointIRVerifier should ignore dead blocks and dead edges.
Jun 14 2018, 7:13 AM

Jun 7 2018

anna added inline comments to D47441: SafepointIRVerifier should ignore dead blocks and dead edges.
Jun 7 2018, 8:31 AM
anna added inline comments to D47441: SafepointIRVerifier should ignore dead blocks and dead edges.
Jun 7 2018, 8:28 AM

Jun 5 2018

anna added a comment to D47441: SafepointIRVerifier should ignore dead blocks and dead edges.

Hi Yevgeny, this looks close to commit. Comments inline.

Jun 5 2018, 12:07 PM

May 29 2018

anna added inline comments to D47441: SafepointIRVerifier should ignore dead blocks and dead edges.
May 29 2018, 10:58 AM

May 23 2018

anna accepted D47197: [MustExecute] Fix a debug invariant issue in isGuaranteedToExecute().

LGTM.

May 23 2018, 7:10 AM

Apr 3 2018

anna accepted D44001: [SCEV] Prove implications for SCEVUnknown Phis.

LGTM

Apr 3 2018, 6:59 AM
anna added inline comments to D44001: [SCEV] Prove implications for SCEVUnknown Phis.
Apr 3 2018, 6:59 AM

Apr 2 2018

anna added inline comments to D44001: [SCEV] Prove implications for SCEVUnknown Phis.
Apr 2 2018, 8:47 AM

Mar 28 2018

anna added a comment to D44001: [SCEV] Prove implications for SCEVUnknown Phis.

Actually ignoring of unreachable predecessors was supposed to be an improvement, but we don't really need it. We can yield it for sake of compile time saving.

Mar 28 2018, 5:41 AM