Page MenuHomePhabricator

nicholas (Nick Lewycky)
User

Projects

User does not belong to any projects.

User Details

User Since
Oct 15 2012, 11:56 PM (452 w, 5 d)

Recent Activity

Apr 29 2021

nicholas committed rG30bbfda01fb6: Improve error messages for attributes in the wrong context. (authored by nicholas).
Improve error messages for attributes in the wrong context.
Apr 29 2021, 1:44 AM
nicholas closed D101484: Improve error messages for attributes in the wrong context..
Apr 29 2021, 1:44 AM · Restricted Project

Apr 28 2021

nicholas committed rG29cb9dc4be25: NFC: Run clang-format over llvm-link. (authored by nicholas).
NFC: Run clang-format over llvm-link.
Apr 28 2021, 2:33 PM

Apr 19 2021

nicholas committed rGcf899a31aebf: Add a cache of checked AttributeLists. (authored by nickwasmer).
Add a cache of checked AttributeLists.
Apr 19 2021, 4:01 PM
nicholas closed D100738: Cache attribute checks.
Apr 19 2021, 4:01 PM · Restricted Project

Apr 16 2021

nicholas committed rG244d9d6e41db: Verify the LLVMContext that an Attribute belongs to. (authored by nickwasmer).
Verify the LLVMContext that an Attribute belongs to.
Apr 16 2021, 9:45 AM
nicholas closed D99362: Verify the LLVMContext for Attributes..
Apr 16 2021, 9:44 AM · Restricted Project

Mar 30 2021

nicholas committed rGc8e56f394af0: Add -disable-verify flag to llvm-link. (authored by nicholas).
Add -disable-verify flag to llvm-link.
Mar 30 2021, 9:55 AM
nicholas closed D99382: Add -disable-verify flag to llvm-link..
Mar 30 2021, 9:55 AM · Restricted Project
nicholas committed rG9ca0b01eb4fd: Remove dead CHECK-ERR line. (authored by nicholas).
Remove dead CHECK-ERR line.
Mar 30 2021, 9:31 AM

Mar 24 2021

nicholas committed rG80f6c99a78ac: Verify that MDNodes belong to the same context as the Module. (authored by nicholas).
Verify that MDNodes belong to the same context as the Module.
Mar 24 2021, 12:38 PM
nicholas closed D99289: Verify that MDNodes belong to the same context as the Module..
Mar 24 2021, 12:38 PM · Restricted Project

Mar 16 2021

nicholas committed rGb743bbc50586: Add ConstantDataVector::getRaw() to create a constant data vector from raw data. (authored by nickwasmer).
Add ConstantDataVector::getRaw() to create a constant data vector from raw data.
Mar 16 2021, 11:58 AM
nicholas closed D98302: Add ConstantDataVector::getRaw() to create a constant data vector from raw data..
Mar 16 2021, 11:58 AM · Restricted Project

Mar 15 2021

nicholas committed rG483a253ae9b8: NFC: Formatting changes. (authored by nicholas).
NFC: Formatting changes.
Mar 15 2021, 2:27 PM

Nov 30 2020

nicholas added a comment to D78793: Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter..

! In D78793#2424013, @dexonsmith wrote:
In particular, it would be nice if LLVMContext were restricted to types / values / metadata that are purely functional, and anything non-functional or open to interpretation is put on the Module.

  • For values and metadata, this requires some significant work (I have some concrete ideas of how, but it seems quite tangential to this patch).
  • For types, this could be done as a very simple follow-up to the opaque pointer work (@dblaikie @arsenm, not sure if you have thoughts). The Type class would be purely functional, and the struct names would move to a symbol table in each Module. The name is not inherent to the type, it's just a handle that some module wants to use to refer to it (the type itself can be shared between modules even if they disagree about what to call it).

I don't have much to add here, I'd simply recommend that you have a plan for dealing with the problems of type merging and refinement, structs whose members are pointers to that same struct (detect and reject creating a struct that holds itself as a member, %0 = type { \0 }), etc., before making the change.

I'm not familiar with the opaque pointer work and how it affects the types and context.

Yeah, that's exactly what's fixed by the opaque pointer work: it turns the type graph into a DAG. In your example, the type wasn't holding itself as a member (that's not possible), it was holding a pointer to itself as a member. Once pointers are opaque, then it's just holding a pointer, no cycles anymore.

Nov 30 2020, 3:06 PM · Restricted Project, Restricted Project
nicholas added a comment to D78793: Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter..

@nicholas, I missed this when it was reviewed, but seeing it now that you've landed it.

Can you help me understand if there's a deeper motivation than the one in the patch description? I ask because I would have envisioned eventually moving these "named" types to the module (i.e., keep the old API before your change, but change the implementation to make sense of it).

Nov 30 2020, 2:34 PM · Restricted Project, Restricted Project
nicholas committed rGfe431683484a: Creating a named struct requires only a Context and a name, but looking up a… (authored by nicholas).
Creating a named struct requires only a Context and a name, but looking up a…
Nov 30 2020, 11:35 AM
nicholas closed D78793: Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter..
Nov 30 2020, 11:35 AM · Restricted Project, Restricted Project

Jun 23 2020

nicholas added inline comments to D78793: Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter..
Jun 23 2020, 11:15 AM · Restricted Project, Restricted Project

Jun 22 2020

nicholas updated the diff for D78793: Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter..

Use LLVMGetTypeByName2 in llvm-c-test echo test too.

Jun 22 2020, 11:04 PM · Restricted Project, Restricted Project

Apr 28 2020

nicholas retitled D78793: Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter. from Names for structs held are on the Context, not the Module. Move getTypeByName off Module. to Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter..
Apr 28 2020, 10:11 AM · Restricted Project, Restricted Project

Apr 24 2020

nicholas updated subscribers of D78793: Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter..
Apr 24 2020, 9:09 AM · Restricted Project, Restricted Project

Apr 23 2020

nicholas created D78793: Names for structs are held on the Context, not the Module. Move getTypeByName from Module to Type taking a Context parameter..
Apr 23 2020, 11:18 PM · Restricted Project, Restricted Project

Sep 25 2019

nicholas committed rGf57e968dd036: Improve C API support for atomicrmw and cmpxchg. (authored by nicholas).
Improve C API support for atomicrmw and cmpxchg.
Sep 25 2019, 6:00 PM
nicholas committed rL372938: Improve C API support for atomicrmw and cmpxchg..
Improve C API support for atomicrmw and cmpxchg.
Sep 25 2019, 5:58 PM
nicholas closed D67132: [PATCH] Improve support for atomicrmw and cmpxchg in C API..
Sep 25 2019, 5:57 PM · Restricted Project

Sep 19 2019

nicholas committed rL372355: Request commit access for nicholas.
Request commit access for nicholas
Sep 19 2019, 2:20 PM

Jun 13 2019

nicholas added a comment to D63315: [Attributor] Regularly clear dependences to remove spurious ones.

Could you include a test with this patch?

Jun 13 2019, 10:08 PM · Restricted Project
nicholas added a comment to D63312: [Attributor] Deduce attributes for non-exact functions.

We can, however, use information from non-exact definitions to improve
themselves as they are either replaced as a whole or not at all.

Jun 13 2019, 9:46 PM · Restricted Project
nicholas added inline comments to D63046: [Attributor] Deduce "willreturn" function attribute.
Jun 13 2019, 1:38 PM · Restricted Project

Jun 9 2019

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

Jun 9 2019, 8:17 PM · Restricted Project
nicholas 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.
Jun 9 2019, 8:12 PM · Restricted Project
nicholas added a comment to D59919: [Attributor] Deduce "returned" argument attribute.

Why did the number of nounwinds drop?

Jun 9 2019, 11:39 AM · Restricted Project, Restricted Project

Jun 8 2019

nicholas added a comment to D60074: [Attributor] Deduce "no-recurse" function attribute.

Thanks for the extensive comment!

Is it actually correct to derive norecurse like this?

Suppose I have two functions:

void f(int x) { if (x) { g(); } }
void g() { f(0); }

As far as I can tell, it would be correct to mark g() norecurse. And if g() is marked norecurse, we'll mark f() norecurse, which is wrong.

We should/do not mark g as norecurse in this example. At least not if f is externally visible.

Could you explain a little further? I don't see how changing whether f is externally visible changes whether it's OK to mark g with norecurse. Here's my thinking. If f is externally visible that means it can be called from external code, and we have to make the worst-case assumption about the call stack, but in this case we know that g can't be on the call stack since g doesn't call any external functions. Is that right?

I should have explained this better from the beginning. At the moment, for better or worse, we derive norecurse only if the function does not call a recursive function. I did not want to change this behavior in this patch but I'm willing to investigate if we should. Now, in the example above, f is recursive as it calls g which calls f. And g is recursive as it calls f which was recursive. My internal comment was following this logic: If f was internal, we could (conceptually) eliminate the call of g after IPSCCP and thereby making both functions non-recursive.

Jun 8 2019, 11:52 AM · Restricted Project

Jun 6 2019

nicholas added a comment to D60074: [Attributor] Deduce "no-recurse" function attribute.

Is it actually correct to derive norecurse like this?

Suppose I have two functions:

void f(int x) { if (x) { g(); } }
void g() { f(0); }

As far as I can tell, it would be correct to mark g() norecurse. And if g() is marked norecurse, we'll mark f() norecurse, which is wrong.

We should/do not mark g as norecurse in this example. At least not if f is externally visible.

Jun 6 2019, 1:30 AM · Restricted Project

Apr 27 2019

nicholas updated the diff for D60056: Hoist/sink malloc/free's in LICM..

This update adds a failing test @test21 which demonstrates a miscompile. While we check the block with the free in it for potentially-malloc'ing instructions, we don't examine all the possible paths from where that free was pre-transform to the new location of the free post-transform.

Apr 27 2019, 11:14 AM · Restricted Project

Apr 26 2019

nicholas committed rG1d30f0c93e7c: Fix typo in documentation. (authored by nicholas).
Fix typo in documentation.
Apr 26 2019, 10:59 AM
nicholas committed rCTE359329: Fix typo in documentation..
Fix typo in documentation.
Apr 26 2019, 10:58 AM
nicholas committed rL359329: Fix typo in documentation..
Fix typo in documentation.
Apr 26 2019, 10:54 AM

Apr 16 2019

nicholas added reviewers for D60356: Accelerate isPotentiallyReachable when a DominatorTree is available.: bruno, asbirlea.

CFG.cpp doesn't have many non-cleanup authors, Bruno once made a change all the way back in 2015 to improve the performance of isPotentiallyReachable. Alina, I've added you since you reviewed my previous change to isPotentiallyReachable when it affected LICM. This series of patches improves performance of isPotentiallyReachable, primary by taking advantage of dominator tree properties.

Apr 16 2019, 10:17 PM · Restricted Project
nicholas created D60756: [NFCI] Replace linear scan with bisection..
Apr 16 2019, 12:53 AM · Restricted Project
nicholas created D60755: [NFCI] Improve efficiency of isPotentiallyReachableFromManyDomTree..
Apr 16 2019, 12:49 AM · Restricted Project
nicholas created D60754: Add forEachDescendant to DominatorTree..
Apr 16 2019, 12:47 AM · Restricted Project
nicholas created D60753: [NFCI] Split isPotentiallyReachable into two implementations..
Apr 16 2019, 12:42 AM · Restricted Project
nicholas created D60752: [NFCI] Use less memory by storing the Loop* as visited instead of storing each BasicBlock* in the block as visited..
Apr 16 2019, 12:38 AM · Restricted Project

Apr 15 2019

nicholas added a comment to D60659: [InstCombine] Eliminate stores to constant memory.

Why do you think a store through constant would break subtly? For most users I'd expect a store to a constant to correspond with a write to a read-only page causing a loud crash.

I assume you mean before this patch right? If so, then yes and no. It's possible the constant location is in a readonly page, but I have a lot of downstream constant locations which are intermixed with writeable data. I'm sure other frontends might have the same. Your reasoning may hold specifically for global constants though.

Apr 15 2019, 11:37 AM · Restricted Project

Apr 13 2019

nicholas added a comment to D60659: [InstCombine] Eliminate stores to constant memory.

The two statements:

We could simply say that the store *is undefined*, and prune the path.

and

The motivating case for this involves a memmove to a buffer which is constant down a path which is dynamically dead.

conspire to make me think that pruning the whole path really is the right thing to do. This might be the only hint the compiler has that the path is dead code.

Apr 13 2019, 3:18 PM · Restricted Project

Apr 11 2019

nicholas added inline comments to D60056: Hoist/sink malloc/free's in LICM..
Apr 11 2019, 12:46 PM · Restricted Project
nicholas updated the diff for D60056: Hoist/sink malloc/free's in LICM..
Apr 11 2019, 12:45 PM · Restricted Project

Apr 10 2019

nicholas updated the diff for D60056: Hoist/sink malloc/free's in LICM..
Apr 10 2019, 11:22 PM · Restricted Project

Apr 6 2019

nicholas committed rG383419f70782: [NFC] Fix typo in comment. (authored by nicholas).
[NFC] Fix typo in comment.
Apr 6 2019, 3:05 PM
nicholas committed rL357849: [NFC] Fix typo in comment..
[NFC] Fix typo in comment.
Apr 6 2019, 3:05 PM
nicholas updated the summary of D60356: Accelerate isPotentiallyReachable when a DominatorTree is available..
Apr 6 2019, 12:54 AM · Restricted Project
nicholas updated the summary of D60357: Improve visited block tracking in isPotentiallyReachable..
Apr 6 2019, 12:54 AM · Restricted Project
nicholas updated the summary of D60356: Accelerate isPotentiallyReachable when a DominatorTree is available..
Apr 6 2019, 12:50 AM · Restricted Project

Apr 5 2019

nicholas updated the diff for D60357: Improve visited block tracking in isPotentiallyReachable..
Apr 5 2019, 9:28 PM · Restricted Project
nicholas retitled D60357: Improve visited block tracking in isPotentiallyReachable. from Improve visited block tracking is isPotentiallyReachable. to Improve visited block tracking in isPotentiallyReachable..
Apr 5 2019, 9:28 PM · Restricted Project
nicholas created D60357: Improve visited block tracking in isPotentiallyReachable..
Apr 5 2019, 9:22 PM · Restricted Project
nicholas created D60356: Accelerate isPotentiallyReachable when a DominatorTree is available..
Apr 5 2019, 8:39 PM · Restricted Project

Apr 4 2019

nicholas closed D60171: An unreachable block may have a route to a reachable block, don't fast-path return that it can't..

rL357734

Apr 4 2019, 4:13 PM · Restricted Project
nicholas committed rGa6ed16c98f50: An unreachable block may have a route to a reachable block, don't fast-path… (authored by nicholas).
An unreachable block may have a route to a reachable block, don't fast-path…
Apr 4 2019, 4:09 PM
nicholas committed rL357734: An unreachable block may have a route to a reachable block, don't fast-path….
An unreachable block may have a route to a reachable block, don't fast-path…
Apr 4 2019, 4:08 PM
nicholas updated the summary of D60171: An unreachable block may have a route to a reachable block, don't fast-path return that it can't..
Apr 4 2019, 12:54 PM · Restricted Project

Apr 3 2019

nicholas updated the summary of D60171: An unreachable block may have a route to a reachable block, don't fast-path return that it can't..
Apr 3 2019, 12:20 PM · Restricted Project

Apr 2 2019

nicholas added inline comments to D60031: Split tailcallelim into tailcallmark and tailcallelim.
Apr 2 2019, 10:28 PM · Restricted Project
nicholas created D60171: An unreachable block may have a route to a reachable block, don't fast-path return that it can't..
Apr 2 2019, 7:41 PM · Restricted Project
nicholas updated the diff for D60056: Hoist/sink malloc/free's in LICM..

Fixed creation of invalid IR when the loop exit block we need to insert a free call in, is a catchswitch block.

Apr 2 2019, 1:31 PM · Restricted Project

Apr 1 2019

nicholas updated the diff for D60056: Hoist/sink malloc/free's in LICM..
Apr 1 2019, 7:47 PM · Restricted Project
nicholas added a comment to D60056: Hoist/sink malloc/free's in LICM..

Should I pull it out of hoisting and sinking and into a post-pass like LICM's scalar promotion? Initially I had imagined that it would participate in hoist and sink's queries of whether "are all arguments to this instruction loop invariant (outside the loop)" as hoists instructions iterately, it would hoist malloc like any other instruction. In practice that couldn't happen because the hoist is deferred until sink time.

Apr 1 2019, 7:45 PM · Restricted Project
nicholas added a comment to D60056: Hoist/sink malloc/free's in LICM..

I've only skimmed through the high level comments so far, so if if any of this is addressed inline, just say so.

I was wondering why you phrased this as a combination of hoisting and sinking as opposed to promotion. We have the scalar promotion path, and the basic transform you're doing feels a lot like promotion. I suspect that many of the legality aspects will be common.

Apr 1 2019, 7:02 PM · Restricted Project
nicholas committed rGc0ebfbe3f321: Add an optional list of blocks to avoid when looking for a path in… (authored by nicholas).
Add an optional list of blocks to avoid when looking for a path in…
Apr 1 2019, 6:06 PM
nicholas committed rL357447: Add an optional list of blocks to avoid when looking for a path in….
Add an optional list of blocks to avoid when looking for a path in…
Apr 1 2019, 6:06 PM
nicholas closed D60085: Add an optional list of blocks to avoid when looking for a path in isPotentiallyReachable..
Apr 1 2019, 6:06 PM · Restricted Project
nicholas committed rG1e1e212d274c: [NFC] Remove dead parameter "FreeInLoop", fix some typos and trailing… (authored by nicholas).
[NFC] Remove dead parameter "FreeInLoop", fix some typos and trailing…
Apr 1 2019, 1:42 PM
nicholas committed rL357427: [NFC] Remove dead parameter "FreeInLoop", fix some typos and trailing….
[NFC] Remove dead parameter "FreeInLoop", fix some typos and trailing…
Apr 1 2019, 1:36 PM
nicholas closed D60084: [NFC] Remove dead parameter "FreeInLoop", fix some typos and trailing whitespace..
Apr 1 2019, 1:36 PM · Restricted Project
nicholas closed D60082: Not all blocks are reachable from entry. Don't assume they are..

Committed revision 357425.

Apr 1 2019, 1:13 PM · Restricted Project
nicholas committed rG66d7eb97045e: Not all blocks are reachable from entry. Don't assume they are. (authored by nicholas).
Not all blocks are reachable from entry. Don't assume they are.
Apr 1 2019, 1:05 PM
nicholas committed rL357425: Not all blocks are reachable from entry. Don't assume they are..
Not all blocks are reachable from entry. Don't assume they are.
Apr 1 2019, 1:05 PM
nicholas updated the diff for D60056: Hoist/sink malloc/free's in LICM..
Apr 1 2019, 12:36 PM · Restricted Project
nicholas added inline comments to D60031: Split tailcallelim into tailcallmark and tailcallelim.
Apr 1 2019, 12:19 PM · Restricted Project
nicholas updated the diff for D60056: Hoist/sink malloc/free's in LICM..
Apr 1 2019, 12:01 PM · Restricted Project
nicholas updated the summary of D60056: Hoist/sink malloc/free's in LICM..
Apr 1 2019, 12:01 PM · Restricted Project
nicholas created D60085: Add an optional list of blocks to avoid when looking for a path in isPotentiallyReachable..
Apr 1 2019, 11:55 AM · Restricted Project
nicholas added a reviewer for D60084: [NFC] Remove dead parameter "FreeInLoop", fix some typos and trailing whitespace.: asbirlea.
Apr 1 2019, 11:49 AM · Restricted Project
nicholas created D60084: [NFC] Remove dead parameter "FreeInLoop", fix some typos and trailing whitespace..
Apr 1 2019, 11:48 AM · Restricted Project
nicholas added a reviewer for D60082: Not all blocks are reachable from entry. Don't assume they are.: asbirlea.
Apr 1 2019, 11:47 AM · Restricted Project
nicholas created D60082: Not all blocks are reachable from entry. Don't assume they are..
Apr 1 2019, 11:41 AM · Restricted Project

Mar 31 2019

nicholas added reviewers for D60056: Hoist/sink malloc/free's in LICM.: asbirlea, george.burgess.iv, reames.
Mar 31 2019, 10:24 PM · Restricted Project
nicholas created D60056: Hoist/sink malloc/free's in LICM..
Mar 31 2019, 10:21 PM · Restricted Project

Nov 8 2018

nicholas added a comment to D53556: [Interpreter] Fix out-of-bounds access in ffiInvoke.

Could you commit this patch on my behalf?

Nov 8 2018, 10:34 AM

Oct 23 2018

nicholas accepted D53556: [Interpreter] Fix out-of-bounds access in ffiInvoke.
Oct 23 2018, 12:43 AM

Oct 16 2018

nicholas committed rL344638: Fix typo Registraction --> Registration, and closing link tag..
Fix typo Registraction --> Registration, and closing link tag.
Oct 16 2018, 11:51 AM

Oct 5 2018

nicholas added a comment to D52895: [TailCallElim] Enable marking of calls with byval as tails.

I misspoke, I meant to say please wait for another reviewer. I've been away from LLVM long enough that I don't have enough context to OK patches to land, but I didn't mean that rnk must be the other reviewer. Sorry!

Oct 5 2018, 3:25 PM
nicholas added a comment to D52895: [TailCallElim] Enable marking of calls with byval as tails.

This looks good to me, but please wait for rnk.

Oct 5 2018, 3:23 PM

Oct 4 2018

nicholas added a comment to D52895: [TailCallElim] Enable marking of calls with byval as tails.
In D52895#1255738, @rnk wrote:

Nice!

I don't understand the logical model behind byval, but I'll review the change to TRE under the assumption that the goal of the patch is correct.

You have to hallucinate an implicit memcpy into the call sequence. Its destination is some stack memory allocated during the call sequence not visible from LLVM IR.

Oct 4 2018, 3:16 PM
nicholas added a comment to D52895: [TailCallElim] Enable marking of calls with byval as tails.

I don't understand the logical model behind byval, but I'll review the change to TRE under the assumption that the goal of the patch is correct.

Oct 4 2018, 11:45 AM

Jun 12 2018

nicholas added inline comments to D48100: Append new attributes to the end of an AttributeList..
Jun 12 2018, 3:33 PM

May 21 2018

nicholas added inline comments to D46814: [InstCombine] Fold unfolded masked merge pattern with variable mask!.
May 21 2018, 4:03 PM · Restricted Project