Page MenuHomePhabricator

jdoerfert (Johannes Doerfert)
Argonne National Laboratory

Projects

User does not belong to any projects.

User Details

User Since
Jan 30 2014, 6:27 AM (281 w, 5 d)

Recent Activity

Today

jdoerfert added inline comments to D63049: Coding Standard: Prefer `int` for regular arithmetic.
Tue, Jun 25, 8:52 AM · Restricted Project

Yesterday

jdoerfert accepted D63372: Use "willreturn" function attribute in isGuaranteedToTransferExecutionToSuccessor.

I think this looks fine with one request for change: We "decided" to use enum attributes not string attributes (for willreturn and others).

Mon, Jun 24, 8:00 AM · Restricted Project
jdoerfert added a comment to D63372: Use "willreturn" function attribute in isGuaranteedToTransferExecutionToSuccessor.

Could you run this with the LLVM test suite [0]?
Do you see a difference in statistics, compile time and/or runtime?

If you don't have a computer to do so, let me know.

[0] http://llvm.org/docs/lnt/quickstart.html

I ran LLVM test suite but there was no significant difference in both execution time and runtime.
I want to see stats (NumFnWillReturn and etc.) but I don't know how to gather stats. I ran with TEST_SUITE_COLLECT_STATS=ON but I couldn't merge them. Can you tell me?

Mon, Jun 24, 7:57 AM · Restricted Project
jdoerfert accepted D63379: [Attributor] Deducing existing nounwind attribute..

Is this sufficient to replace the old nounwind deduction? Can you disable the current one to see if there is something we cannot deduce with this one?

I already tried it on some of the other tests and it worked fine. I am going to that and test it some more, and update tomorrow morning.

Sorry for the late update. I ran all tests with -disable-nounwind-inference -attributor -attributor-disable=false and they pass. Is that enough?

Mon, Jun 24, 7:53 AM · Restricted Project
jdoerfert added a comment to D62766: [Attributor] Deduce "nosync" function attribute..

Just realized that the basic attribute test in test/Bitcode/attributes.ll is missing, see https://reviews.llvm.org/D49165#change-K8gwLFRSXwEe for an example.

Mon, Jun 24, 7:48 AM · Restricted Project
jdoerfert added a comment to D61652: [Attr] Introduce dereferenceable_globally.

@reames Was the last comment a "LGTM"? I need to start getting these patches of my plate :(

Mon, Jun 24, 7:32 AM · Restricted Project
jdoerfert added a comment to D62766: [Attributor] Deduce "nosync" function attribute..

Sorry for my delayed review, I want to move this ahead now and commit it.

Mon, Jun 24, 7:22 AM · Restricted Project
jdoerfert added inline comments to D62397: [OPENMP][NVPTX]Relax flush directive..
Mon, Jun 24, 7:14 AM · Restricted Project

Fri, Jun 21

jdoerfert requested changes to D62397: [OPENMP][NVPTX]Relax flush directive..
Fri, Jun 21, 8:54 AM · Restricted Project

Wed, Jun 19

jdoerfert added inline comments to D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally.
Wed, Jun 19, 3:06 AM · Restricted Project
jdoerfert added a comment to D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..

I want to investigate the racy accesses further and make sure it is not a miscompile inside LLVM.

This is not a problem inside LLVM. The problem appears after optimizations performed by the ptxas tool (when it compiles PTX to SASS) at O3 with the inlined runtime.

I extracted the test case (see below) but I was not seeing the ERROR. How did you run the test case to see a different value for Count?

You need to compile it with the inlined runtime at O2 or O3.

When I run
./bin/clang -fopenmp-targets=nvptx64-nvida-cuda -O3 -fopenmp --cuda-path=/soft/compilers/cuda/cuda-9.1.85 -Xopenmp-target -march=sm_70 -fopenmp=libomp test.c -o test.ll -emit-llvm -S
I get

https://gist.github.com/jdoerfert/4376a251d98171326d625f2fb67b5259

which shows the inlined and optimized libomptarget.

And you need the latest version of the libomptarget

My version is from today Jun 13 15:24:11 2019, git: 3bc6e2a7aa3853b06045c42e81af094647c48676

We have problems in Cuda 8, at least, for arch sm_35

I couldn't get that version to run properly so I asked someone who had a system set up.
Unfortunately, the test.c [1] did not trigger the problem. In test.c we run the new test part in spmd_parallel_regions.cpp 1000 times and check the result each time.
It was run with Cuda 8.0 for sm_35, sm_37, and sm_70.

Could you share more information on how the system has to look to trigger the problem?
Could you take a look at the test case we run and make sure it triggers the problem on your end?

[1] https://gist.github.com/jdoerfert/d2b18ca8bb5c3443cc1d26b23236866f

You need to apply the patch D62318 to reproduce the problem for sure.

Wed, Jun 19, 1:26 AM · Restricted Project

Tue, Jun 18

jdoerfert added inline comments to D63372: Use "willreturn" function attribute in isGuaranteedToTransferExecutionToSuccessor.
Tue, Jun 18, 1:27 AM · Restricted Project
jdoerfert added inline comments to D63067: [Attributor] NoAlias on return values..
Tue, Jun 18, 1:26 AM · Restricted Project
jdoerfert added a comment to D63372: Use "willreturn" function attribute in isGuaranteedToTransferExecutionToSuccessor.

Could you run this with the LLVM test suite [0]?
Do you see a difference in statistics, compile time and/or runtime?

Tue, Jun 18, 1:26 AM · Restricted Project
jdoerfert added inline comments to D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally.
Tue, Jun 18, 1:18 AM · Restricted Project
jdoerfert added a comment to D63379: [Attributor] Deducing existing nounwind attribute..

Is this sufficient to replace the old nounwind deduction? Can you disable the current one to see if there is something we cannot deduce with this one?

Tue, Jun 18, 1:12 AM · Restricted Project

Fri, Jun 14

jdoerfert updated the diff for D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally.

Update all uses of isDereferenceablePointer

Fri, Jun 14, 11:18 AM · Restricted Project
jdoerfert added inline comments to D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally.
Fri, Jun 14, 11:06 AM · Restricted Project
jdoerfert updated the diff for D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally.

Update according to API suggestion

Fri, Jun 14, 11:06 AM · Restricted Project
jdoerfert requested changes to D50554: [ValueTracking] Accept vectors of pointer in GetUnderlyingObject utility.

What is supposed to happen if the elements in the pointer vector have different underlying objects?
We need to document that in the comment and test it.

Fri, Jun 14, 10:28 AM
jdoerfert added a comment to D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..

I want to investigate the racy accesses further and make sure it is not a miscompile inside LLVM.

This is not a problem inside LLVM. The problem appears after optimizations performed by the ptxas tool (when it compiles PTX to SASS) at O3 with the inlined runtime.

I extracted the test case (see below) but I was not seeing the ERROR. How did you run the test case to see a different value for Count?

You need to compile it with the inlined runtime at O2 or O3.

When I run
./bin/clang -fopenmp-targets=nvptx64-nvida-cuda -O3 -fopenmp --cuda-path=/soft/compilers/cuda/cuda-9.1.85 -Xopenmp-target -march=sm_70 -fopenmp=libomp test.c -o test.ll -emit-llvm -S
I get

https://gist.github.com/jdoerfert/4376a251d98171326d625f2fb67b5259

which shows the inlined and optimized libomptarget.

And you need the latest version of the libomptarget

My version is from today Jun 13 15:24:11 2019, git: 3bc6e2a7aa3853b06045c42e81af094647c48676

We have problems in Cuda 8, at least, for arch sm_35

Fri, Jun 14, 10:16 AM · Restricted Project
jdoerfert committed rG282d34ee78cd: [Attributor] Disable the Attributor by default and fix a comment (authored by jdoerfert).
[Attributor] Disable the Attributor by default and fix a comment
Fri, Jun 14, 7:51 AM
jdoerfert committed rGd85dd0f0c9e9: [Attributor] Introduce bit-encodings for abstract states (authored by jdoerfert).
[Attributor] Introduce bit-encodings for abstract states
Fri, Jun 14, 7:51 AM
jdoerfert committed rL363408: [Attributor] Disable the Attributor by default and fix a comment.
[Attributor] Disable the Attributor by default and fix a comment
Fri, Jun 14, 7:50 AM
jdoerfert committed rL363407: [Attributor] Introduce bit-encodings for abstract states.
[Attributor] Introduce bit-encodings for abstract states
Fri, Jun 14, 7:50 AM
jdoerfert closed D60012: [Attributor] Introduce bit-encodings for abstract states.
Fri, Jun 14, 7:50 AM · Restricted Project

Thu, Jun 13

jdoerfert created D63319: [Attributor] Use internalized versions of non-exact functions.
Thu, Jun 13, 11:38 PM · Restricted Project
jdoerfert added a comment to D63315: [Attributor] Regularly clear dependences to remove spurious ones.

Could you include a test with this patch?

Thu, Jun 13, 10:55 PM · Restricted Project
jdoerfert created D63317: [Attributor] Recompute dependences once a fixpoint is reached.
Thu, Jun 13, 10:55 PM · Restricted Project
jdoerfert added a comment to D63312: [Attributor] Deduce attributes for non-exact functions.

Thanks for the quick feedback!

Thu, Jun 13, 10:49 PM · Restricted Project
jdoerfert created D63315: [Attributor] Regularly clear dependences to remove spurious ones.
Thu, Jun 13, 10:02 PM · Restricted Project
jdoerfert created D63314: [Attributor] Allow explicit dependence tracking.
Thu, Jun 13, 9:27 PM · Restricted Project
jdoerfert created D63312: [Attributor] Deduce attributes for non-exact functions.
Thu, Jun 13, 7:04 PM · Restricted Project
jdoerfert added inline comments to D63046: [Attributor] Deduce "willreturn" function attribute.
Thu, Jun 13, 3:27 PM · Restricted Project
jdoerfert added a comment to D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..

I want to investigate the racy accesses further and make sure it is not a miscompile inside LLVM.

This is not a problem inside LLVM. The problem appears after optimizations performed by the ptxas tool (when it compiles PTX to SASS) at O3 with the inlined runtime.

I extracted the test case (see below) but I was not seeing the ERROR. How did you run the test case to see a different value for Count?

You need to compile it with the inlined runtime at O2 or O3.

Thu, Jun 13, 3:24 PM · Restricted Project
jdoerfert updated the diff for D59919: [Attributor] Deduce "returned" argument attribute.

Simplify the interface

Thu, Jun 13, 2:26 PM · Restricted Project, Restricted Project
jdoerfert added a comment to D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..

It makes me suspicious of that too. But no one here believes that anyone was trying to subvert the system and produce an inferior result - it is very likely that everyone had, and continues to have, the best of intentions.

Maybe, just maybe, before starting treat someone's activity "suspicious" better to start to try to understand something? To read something, to ask the questions in the proper manner, etc.?

Thu, Jun 13, 2:09 PM · Restricted Project
jdoerfert updated subscribers of D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..

I want to investigate the racy accesses further and make sure it is not a miscompile inside LLVM.
I extracted the test case (see below) but I was not seeing the ERROR. How did you run the test case to see a different value for Count?

Thu, Jun 13, 12:56 PM · Restricted Project
jdoerfert added inline comments to D49165: Add, and infer, a nofree function attribute.
Thu, Jun 13, 9:07 AM · Restricted Project
jdoerfert added a comment to D62687: [Attributor] Deduce "nofree" function attribute.

Can you make the test use an enum version, thus nofree not "nofree".

Thu, Jun 13, 8:49 AM · Restricted Project
jdoerfert accepted D62313: Add a test for "nofree" function attribute.
Thu, Jun 13, 8:49 AM · Restricted Project

Wed, Jun 12

jdoerfert updated the diff for D61652: [Attr] Introduce dereferenceable_globally.

DereferenceableOrNullBytesGlobally -> DereferenceableOrNullGloballyBytes

Wed, Jun 12, 11:24 PM · Restricted Project
jdoerfert added inline comments to D62766: [Attributor] Deduce "nosync" function attribute..
Wed, Jun 12, 11:21 PM · Restricted Project
jdoerfert abandoned D62784: [NFC] Include short string attributes in the "Function Attrs" comment.

I give up on this for now. If there is interest in this we can revive it later.

Wed, Jun 12, 11:07 PM · Restricted Project
jdoerfert added a child revision for D62766: [Attributor] Deduce "nosync" function attribute.: D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally.
Wed, Jun 12, 11:05 PM · Restricted Project
jdoerfert added parent revisions for D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally: D61652: [Attr] Introduce dereferenceable_globally, D49165: Add, and infer, a nofree function attribute, D62766: [Attributor] Deduce "nosync" function attribute..
Wed, Jun 12, 11:05 PM · Restricted Project
jdoerfert added a child revision for D49165: Add, and infer, a nofree function attribute: D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally.
Wed, Jun 12, 11:05 PM · Restricted Project
jdoerfert added a child revision for D61652: [Attr] Introduce dereferenceable_globally: D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally.
Wed, Jun 12, 11:05 PM · Restricted Project
jdoerfert created D63243: [WIP] Adjust the users of dereferenceable wrt. dereferenceable_globally.
Wed, Jun 12, 11:04 PM · Restricted Project
jdoerfert updated the diff for D61652: [Attr] Introduce dereferenceable_globally.

Minor fixes

Wed, Jun 12, 10:58 PM · Restricted Project
jdoerfert updated subscribers of D62313: Add a test for "nofree" function attribute.

As mentioned in D62766, we should make nofree an enum attribute. See D62766 for some pointer on how to do so.

As I see it, D49165 is rebased.
Which is better to wait for D49165 or to make nofree enum attribute in this patch?

Wed, Jun 12, 10:20 PM · Restricted Project
jdoerfert added a comment to D61652: [Attr] Introduce dereferenceable_globally.

Wow, we have a huge amount of boilerplate when adding an attribute.

Wed, Jun 12, 8:18 PM · Restricted Project
jdoerfert updated the diff for D61652: [Attr] Introduce dereferenceable_globally.

Addressed comments: Getter/Setter rename + for loop

Wed, Jun 12, 8:18 PM · Restricted Project
jdoerfert added inline comments to rL363222: [SimplifyCFG] NFC, update Switch tests to HEAD so I can.
Wed, Jun 12, 8:04 PM
jdoerfert added a comment to D61652: [Attr] Introduce dereferenceable_globally.

The getter/setter functions are called "DereferenceableBytesGlobally" not "DereferenceableGloballyBytes". I would like to get some feedback on this.

Wed, Jun 12, 7:04 PM · Restricted Project
jdoerfert updated the diff for D61652: [Attr] Introduce dereferenceable_globally.

Add all the mechanics for dereferenceable_globally we have for dereferenceable

Wed, Jun 12, 6:02 PM · Restricted Project
jdoerfert retitled D61652: [Attr] Introduce dereferenceable_globally from [LangRef][Attr] Clarify dereferenceable(_in_scope) to [Attr] Introduce dereferenceable_globally.
Wed, Jun 12, 5:56 PM · Restricted Project
jdoerfert requested changes to D62313: Add a test for "nofree" function attribute.

As mentioned in D62766, we should make nofree an enum attribute. See D62766 for some pointer on how to do so.

Wed, Jun 12, 5:16 PM · Restricted Project
jdoerfert requested changes to D62766: [Attributor] Deduce "nosync" function attribute..
Wed, Jun 12, 5:15 PM · Restricted Project
jdoerfert added a comment to D61652: [Attr] Introduce dereferenceable_globally.

Sorry for the late reply. Replying selectively to key points.

The discussion with @sanjoy lead to the change from scope to globally, maybe that resolves this?

It does. The globally wording seems broad enough. You're missing a bunch of detail from the original spec which needs to be preserved, but the basic notion seems reasonable.

Please elaborate on the details I'm missing,

The main thing is your missing the wording about restrictions on where the attribute can be applied (i.e. pointer types). Reading the existing dereferenceable_or_null wording more careful, we have precedent for just assuming it carries over to other dereferenceable* flavours, so I'll drop this objection. I may separately post a patch to refine the wording, but this is not a key issue.

Now, my remaining concern. This patch, as structured, introduces a number of purely definitional miscompiles into LLVM. There are existing transformations which assume the dereferenceable global property for correctness. By introducing a new attribute with the old semantics, and not updating all of the existing code to use the new attribute (code, tests, etc..), you're are defining (via the langref change) existing optimizations to be incorrect.

I really don't think that's okay. Particular, since it should be very easy to fix. A simple find replace in source and tests which replaces checks for dereferenceable with checks for dereferenceable_globally should be all that's needed.

I'm specifically asking that this change not be committed - despite Hal's LGTM - before this point is addressed.

p.s. I wouldn't be thrilled by it, but I'd even be okay with a clear statement of intent to handle this in follow up changes. It is more of a theoretical problem than a practical one in the near term.

Wed, Jun 12, 4:51 PM · Restricted Project
jdoerfert updated the diff for D61652: [Attr] Introduce dereferenceable_globally.

Add argument definitions

Wed, Jun 12, 3:27 PM · Restricted Project
jdoerfert updated the diff for D61652: [Attr] Introduce dereferenceable_globally.

Remove the alignment part

Wed, Jun 12, 3:19 PM · Restricted Project
jdoerfert added inline comments to D61962: [LoopUnroll] Add support for loops with exiting headers and uncond latches..
Wed, Jun 12, 12:46 PM · Restricted Project
jdoerfert added a comment to D63067: [Attributor] NoAlias on return values..

We need more test cases, e.g. as the one below which shows some limits of the current impl.

Wed, Jun 12, 9:07 AM · Restricted Project

Tue, Jun 11

jdoerfert added a comment to D63046: [Attributor] Deduce "willreturn" function attribute.

@nicholas If you want to discuss any of this further, please say so.

Tue, Jun 11, 10:23 PM · Restricted Project
jdoerfert added a comment to D63036: LLVM IR constant expressions never trap..

Is this still an RFC or by now an accumulation of changes we actually want to make? I added to comments assuming the latter.

Tue, Jun 11, 10:13 PM · Restricted Project
jdoerfert accepted D63158: StackProtector: Use PointerMayBeCaptured.

This looks good to me (LGTM). Give it a bit of time though for people familiar with this code to take a look if they want.

Tue, Jun 11, 9:24 PM
jdoerfert added inline comments to D63158: StackProtector: Use PointerMayBeCaptured.
Tue, Jun 11, 5:33 PM
jdoerfert added a comment to D63067: [Attributor] NoAlias on return values..

More comments. Can you diff it against the master branch so one can easily see all changes?

Tue, Jun 11, 4:44 PM · Restricted Project
jdoerfert added a comment to D63158: StackProtector: Use PointerMayBeCaptured.

Generally fine, three smaller comments though.

Tue, Jun 11, 4:36 PM
jdoerfert added a comment to D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..

This is a clarrification for some older comments.

Tue, Jun 11, 4:22 PM · Restricted Project
jdoerfert resigned from D37901: [Polly] [Strided arrays, multidimensional indexing, fortran support] Teach Polly multidimensional strided array indexing. [WIP].
Tue, Jun 11, 7:59 AM
jdoerfert resigned from D31842: [Polly] Load hoisting of indirect loads.
Tue, Jun 11, 7:59 AM
jdoerfert resigned from D33256: [Polly] [Fortran Support] Generate GPU kernels for Fortran arrays.
Tue, Jun 11, 7:59 AM
jdoerfert added a comment to D63067: [Attributor] NoAlias on return values..

Why should the return values in nonnull.ll be noalias?

All functions returning pointer never actually capture it, or they return null. Isn't that enough?

This doesn't seem sufficient to me.
Consider:

file1.c
int* getter();
int* callee0() { // will get marked as noalias
  return getter();
}
int* callee1() { // will get marked as noalias
  return getter();
}
int entry() {
  int* p0 = callee0();
  int* p1 = callee1();
  // do p0 and p1 alias?
}

file2.c
int* global;
int* getter() { return global; } // oops
Tue, Jun 11, 7:39 AM · Restricted Project

Mon, Jun 10

jdoerfert updated the diff for D59919: [Attributor] Deduce "returned" argument attribute.

Update tests

Mon, Jun 10, 10:18 PM · Restricted Project, Restricted Project
jdoerfert added a comment to D63067: [Attributor] NoAlias on return values..

Why should the return values in nonnull.ll be noalias?

Mon, Jun 10, 7:24 PM · Restricted Project
jdoerfert added a comment to D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..

> The standard has "levels" and "active-levels". Both need to be tracked but it seems we only have a single array?
>

They all are tracked on this array.

Where is that described?

Sorry, read the code. I'm not a debugger.

Mon, Jun 10, 6:01 PM · Restricted Project
jdoerfert added inline comments to D63036: LLVM IR constant expressions never trap..
Mon, Jun 10, 3:10 PM · Restricted Project
jdoerfert added a comment to D63044: [LangRef] Clarify poison semantics.

LGTM as well. Thanks!

Mon, Jun 10, 1:24 PM · Restricted Project
jdoerfert added a comment to D59919: [Attributor] Deduce "returned" argument attribute.

CHANGED: build-libcalls NumNoUnwind 4526 -> 3382 ( -25.276%)

Why did the number of nounwinds drop?

Mon, Jun 10, 12:44 PM · Restricted Project, Restricted Project
jdoerfert updated the summary of D59919: [Attributor] Deduce "returned" argument attribute.
Mon, Jun 10, 12:41 PM · Restricted Project, Restricted Project
jdoerfert updated the diff for D59919: [Attributor] Deduce "returned" argument attribute.

Fix Typo

Mon, Jun 10, 7:22 AM · Restricted Project, Restricted Project
jdoerfert updated the diff for D59919: [Attributor] Deduce "returned" argument attribute.

Use worklist instead of recursion, add tests

Mon, Jun 10, 7:21 AM · Restricted Project, Restricted Project
jdoerfert added inline comments to D63046: [Attributor] Deduce "willreturn" function attribute.
Mon, Jun 10, 7:19 AM · Restricted Project

Sun, Jun 9

jdoerfert added a comment to D63046: [Attributor] Deduce "willreturn" function attribute.

The current algorithm can deduce only for very simple cases.

  • A function doesn't have any loop.
  • A function doesn't have any recursion.

What about functions that exit the program, throw an exception, or longjmp?

Sun, Jun 9, 8:36 PM · Restricted Project
jdoerfert added a comment to D62687: [Attributor] Deduce "nofree" function attribute.

Why does this depend on D63046?

Sun, Jun 9, 8:36 PM · Restricted Project
jdoerfert added inline comments to D63067: [Attributor] NoAlias on return values..
Sun, Jun 9, 8:24 PM · Restricted Project
jdoerfert accepted D63046: [Attributor] Deduce "willreturn" function attribute.

Move the isKnownWillReturn isAssumedWillReturn and the to string function to the base class. Then place the base class in the header. Otherwise, LGTM.

Sun, Jun 9, 6:04 PM · Restricted Project
jdoerfert added a comment to D62784: [NFC] Include short string attributes in the "Function Attrs" comment.

@pcc So I thought about this. I don't think printing all attributes always helps. Testing for a single "Function Attrs" line will be very brittle, the use of multiple check lines will make tests harder to read/write/maintain and the IR output is cluttered. What if we have an output like this one under a flag? It would have all the benefits this patch has and, as you seem to dislike it, it would be on an opt-in basis. Though, I'm still unsure under which circumstance this patch would be worse than the status quo.

Sun, Jun 9, 3:23 PM · Restricted Project
jdoerfert added a comment to D63046: [Attributor] Deduce "willreturn" function attribute.

Can you clang format the code?

I always clang format before submitting a patch.
Is there something wrong?

Sun, Jun 9, 3:18 PM · Restricted Project
jdoerfert accepted D63057: [bindings/go][NFC] Format code with go fmt.

LGTM

Sun, Jun 9, 3:04 PM · Restricted Project
jdoerfert added a comment to D60047: [CaptureTracking] Don't let comparisons against null escape inbounds pointers.

Phabricator says:

This revision was not accepted when it landed

but I believe that's in error because it was not marked as accepted (while it was in practice).

Sun, Jun 9, 3:02 PM · Restricted Project
jdoerfert added a comment to D59919: [Attributor] Deduce "returned" argument attribute.

Thanks for looking at this. I'll update the patch asap

Sun, Jun 9, 1:23 PM · Restricted Project, Restricted Project
jdoerfert added inline comments to D63044: [LangRef] Clarify poison semantics.
Sun, Jun 9, 1:11 PM · Restricted Project
jdoerfert updated the diff for D59919: [Attributor] Deduce "returned" argument attribute.

Cleanup leftover arguments

Sun, Jun 9, 9:04 AM · Restricted Project, Restricted Project
jdoerfert updated the summary of D59919: [Attributor] Deduce "returned" argument attribute.
Sun, Jun 9, 9:00 AM · Restricted Project, Restricted Project
jdoerfert updated the diff for D59919: [Attributor] Deduce "returned" argument attribute.

Update to new Attributor design and more tests

Sun, Jun 9, 8:59 AM · Restricted Project, Restricted Project
jdoerfert added inline comments to D63044: [LangRef] Clarify poison semantics.
Sun, Jun 9, 8:34 AM · Restricted Project

Sat, Jun 8

jdoerfert added a comment to D60619: New pass to produce more easily-read IR..

I haven't had time to read through the explanation that is to become a comment yet.

Sat, Jun 8, 4:17 PM · Restricted Project