Page MenuHomePhabricator

greened (David Greene)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 1 2015, 10:19 AM (207 w, 6 d)

Recent Activity

Fri, Jun 21

greened added inline comments to D63507: Teach TableGen Intrin Emitter to handle LLVMPointerType<llvm_any_ty>.
Fri, Jun 21, 10:10 AM · Restricted Project

Thu, Jun 20

greened added inline comments to D63507: Teach TableGen Intrin Emitter to handle LLVMPointerType<llvm_any_ty>.
Thu, Jun 20, 1:25 PM · Restricted Project
greened added a comment to D63507: Teach TableGen Intrin Emitter to handle LLVMPointerType<llvm_any_ty>.

Unfortunately, I've never worked in the IntrinsicEmitter so I can't really comment on the correctness of the patch. I will make some inline comments on non-correctness things.

Thu, Jun 20, 1:22 PM · Restricted Project
greened added a comment to D63614: [System Model] [TTI] Update cache and prefetch TTI interfaces.

This is the subset of D58736 covering changes to TTI and related classes. It does not introduce any new functionality, only reorganizes things a bit to move implementations into subtargets in preparation for defining system models for targets.

Thu, Jun 20, 10:20 AM · Restricted Project
greened added a comment to D58736: [System Model] Introduce a target system model.

I just posted D63614, the subset of this patch covering only the changes to TTI and related classes.

Thu, Jun 20, 10:19 AM · Restricted Project
greened created D63614: [System Model] [TTI] Update cache and prefetch TTI interfaces.
Thu, Jun 20, 10:17 AM · Restricted Project
greened added inline comments to D58736: [System Model] Introduce a target system model.
Thu, Jun 20, 10:05 AM · Restricted Project

Fri, Jun 14

greened updated the summary of D58736: [System Model] Introduce a target system model.
Fri, Jun 14, 1:37 PM · Restricted Project
greened updated the diff for D58736: [System Model] Introduce a target system model.

Updated to address comments.

Fri, Jun 14, 1:34 PM · Restricted Project

Tue, May 28

greened committed rG561fcc0d63ca: [X86-64] Fix 256-bit SET0 lowering for non-VLX targets (authored by greened).
[X86-64] Fix 256-bit SET0 lowering for non-VLX targets
Tue, May 28, 8:37 AM
greened committed rL361843: [X86-64] Fix 256-bit SET0 lowering for non-VLX targets.
[X86-64] Fix 256-bit SET0 lowering for non-VLX targets
Tue, May 28, 8:37 AM
greened closed D62415: [X86-64] Fix 256-bit SET0 lowering for non-VLX targets.
Tue, May 28, 8:37 AM · Restricted Project

May 26 2019

greened updated the diff for D62415: [X86-64] Fix 256-bit SET0 lowering for non-VLX targets.

Added testcase.

May 26 2019, 2:26 PM · Restricted Project

May 24 2019

greened added a comment to D62415: [X86-64] Fix 256-bit SET0 lowering for non-VLX targets.

Oops, needs a testcase. Will add.

May 24 2019, 11:35 AM · Restricted Project
greened created D62415: [X86-64] Fix 256-bit SET0 lowering for non-VLX targets.
May 24 2019, 11:35 AM · Restricted Project

May 13 2019

greened added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

I know very well how annoying it can be to read and write (and say) the scalable prefix all the time and wish for something shorter sometimes, but I also prefer <vscale x ...> for the reasons Sander gave. I'll add that <vscale x 4 x i32> feels a bit lighter than <scalable 4 x i32> even though it's the same number of characters (maybe because there's more whitespace?).

The <n x ...> syntax is shorter but doesn't have the mnemonic aspect and also clashes with the pre-existing use of "n" as a metavariable standing for some fixed vector length (as in, <N x i1> for example), so I'd rather have <scalable ...> if those are the two options.

May 13 2019, 11:48 AM · Restricted Project

May 9 2019

greened added a comment to D61089: [Reassociation] Place moved instructions after landing pads.

Looks like some lines got truncated from the head of the first test file. Test is failing due to no run line.

May 9 2019, 10:45 AM · Restricted Project
greened added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

What's the status of this? It seems like discussion has died down a bit. I think Graham's idea to change from <scalable 2 x float> to <vscale x 2 x float> will make the IR more readable/understandable but it's not a show-stopper for me.

May 9 2019, 10:33 AM · Restricted Project

May 8 2019

greened committed rG6c433713e91b: [Reassociation] Place moved instructions after landing pads (authored by greened).
[Reassociation] Place moved instructions after landing pads
May 8 2019, 8:43 AM
greened committed rL360262: [Reassociation] Place moved instructions after landing pads.
[Reassociation] Place moved instructions after landing pads
May 8 2019, 8:42 AM
greened closed D61089: [Reassociation] Place moved instructions after landing pads.
May 8 2019, 8:42 AM · Restricted Project

May 7 2019

greened updated the diff for D61089: [Reassociation] Place moved instructions after landing pads.

Added a test for catchswitch and fixed a bug with falling off the end of a basic block.

May 7 2019, 6:43 AM · Restricted Project

May 1 2019

greened updated the diff for D61089: [Reassociation] Place moved instructions after landing pads.

Updated to account for isEHPad including catchswitch. I'm not very happy with the hacky use of FoundCatchSwitch but could not think of a way to do this that keeps things relatively clear/readable and doesn't put the for loop into a deeper nesting level or completely reformat the function.

May 1 2019, 10:39 AM · Restricted Project
greened added inline comments to D61089: [Reassociation] Place moved instructions after landing pads.
May 1 2019, 10:38 AM · Restricted Project

Apr 30 2019

greened updated the summary of D61089: [Reassociation] Place moved instructions after landing pads.
Apr 30 2019, 1:39 PM · Restricted Project
greened updated the diff for D61089: [Reassociation] Place moved instructions after landing pads.

Bail out of the loop that found an existing neg if there is a catchswitch
and just create a new neg instead.

Apr 30 2019, 1:38 PM · Restricted Project
greened added inline comments to D61089: [Reassociation] Place moved instructions after landing pads.
Apr 30 2019, 1:37 PM · Restricted Project
greened added inline comments to D61089: [Reassociation] Place moved instructions after landing pads.
Apr 30 2019, 1:08 PM · Restricted Project
greened updated the diff for D61089: [Reassociation] Place moved instructions after landing pads.

Updated to use isEHPad.

Apr 30 2019, 1:07 PM · Restricted Project
greened added inline comments to D61089: [Reassociation] Place moved instructions after landing pads.
Apr 30 2019, 12:53 PM · Restricted Project
greened added inline comments to D32530: [SVE][IR] Scalable Vector IR Type.
Apr 30 2019, 12:32 PM · Restricted Project

Apr 29 2019

greened updated the diff for D61089: [Reassociation] Place moved instructions after landing pads.

Rebased on latest master and fixed test name.

Apr 29 2019, 12:23 PM · Restricted Project

Apr 24 2019

greened created D61089: [Reassociation] Place moved instructions after landing pads.
Apr 24 2019, 1:37 PM · Restricted Project

Apr 22 2019

greened added a comment to D32530: [SVE][IR] Scalable Vector IR Type.
Apr 22 2019, 12:12 PM · Restricted Project

Apr 17 2019

greened added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

We need to clarify on insertelement/extractelement. Maybe already done in some other patches, but that clarification should be part of this patch.
Is the "length of val" under the semantics "scalable * n" in <scalable n x ElemTy>, right? Or is it still n?

Apr 17 2019, 1:54 PM · Restricted Project

Apr 3 2019

greened added inline comments to D58736: [System Model] Introduce a target system model.
Apr 3 2019, 2:51 PM · Restricted Project
greened added a comment to D58736: [System Model] Introduce a target system model.

This takes a while to digest. Some quick remarks for now (also inline):

Apr 3 2019, 2:22 PM · Restricted Project
greened added a comment to D58736: [System Model] Introduce a target system model.

Thank you for pushing this forward and sorry for the delay.

Could you add some central high-level documentation about what the memory system model is? E.g. describe that an MCSystemModel has a list of execution resources, memory hierarchies, prefetch configs and write-combining buffers. A Cache hierarchy as a total size, line size, associativity, etc. To get the interpretation eight, please add more details about ever parameter, particularly the prefetch configs. Some other examples than ARM big.LITTLE would be nice as well.

Apr 3 2019, 2:18 PM · Restricted Project

Mar 20 2019

greened added inline comments to D32530: [SVE][IR] Scalable Vector IR Type.
Mar 20 2019, 11:11 AM · Restricted Project

Mar 14 2019

greened added a comment to D58736: [System Model] Introduce a target system model.

Ping?

Mar 14 2019, 1:38 PM · Restricted Project

Mar 8 2019

greened added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

This all LGTM.

Mar 8 2019, 7:31 AM · Restricted Project
greened added inline comments to D47770: [MVT][SVE] Add EVT strings and Type mapping.
Mar 8 2019, 7:28 AM

Mar 7 2019

greened added inline comments to D47770: [MVT][SVE] Add EVT strings and Type mapping.
Mar 7 2019, 1:58 PM
greened added a reviewer for D32530: [SVE][IR] Scalable Vector IR Type: greened.
Mar 7 2019, 1:54 PM · Restricted Project
greened added a comment to D53137: Scalable type size queries (llvm).

I know this isn't ready for merge, but since the mailing list discussion has died down it seems like maybe we should move the discussion here. If so, it would be helpful to have comments on all the routines explaining what they do and how they differ from the existing routines, in order to aid discussion.

Mar 7 2019, 1:52 PM

Mar 6 2019

greened added a comment to D58736: [System Model] Introduce a target system model.

Ping?

Mar 6 2019, 9:04 AM · Restricted Project

Feb 28 2019

greened added a comment to D58775: [Tablegen] Add support for the !mul operator..

Cool,. I've wanted this for a while. LGTM.

Feb 28 2019, 9:44 AM · Restricted Project
greened added a comment to D58546: [lit] Honor PYTHONPATH for llvm tests.

If we do this, should we do it in lit? Else we probably need to do it in llvm, clang, lld, clang-tools-extra, etc etc etc.

Feb 28 2019, 8:17 AM · Restricted Project

Feb 27 2019

greened added a comment to D58736: [System Model] Introduce a target system model.

A larger design question I have about this is the proper place to put software prefetching configuration. Right now it lives at the memory model level, in that a memory model specifies a cache heirachy along with a software prefetch configuration. I wonder if we should allow for software prefetching configuration for each cache level, as targets might want different policies depending on which cache level they are prefetching into. I don't think we have any examples of that in the codebase today but I can imagine cases where targets might want it.

Feb 27 2019, 2:19 PM · Restricted Project
greened created D58736: [System Model] Introduce a target system model.
Feb 27 2019, 1:38 PM · Restricted Project
greened added a comment to D57806: [Interpreter] Add newline to interpreter debugging output.

LGTM.

Feb 27 2019, 1:16 PM · Restricted Project

Feb 22 2019

greened abandoned D56202: [OpenMP] Remove -fno-experimental-isel from OMP testing.

I believe https://reviews.llvm.org/D56266 is working for me.

Feb 22 2019, 1:23 PM · Restricted Project
greened committed rG3b9141df25df: [CMake] Honor LLVM_EXTERNAL_<proj>_SOURCE_DIR (authored by greened).
[CMake] Honor LLVM_EXTERNAL_<proj>_SOURCE_DIR
Feb 22 2019, 1:20 PM
greened committed rL354693: [CMake] Honor LLVM_EXTERNAL_<proj>_SOURCE_DIR.
[CMake] Honor LLVM_EXTERNAL_<proj>_SOURCE_DIR
Feb 22 2019, 1:19 PM
greened closed D49672: [CMake] Honor LLVM_EXTERNAL_<proj>_SOURCE_DIR.
Feb 22 2019, 1:19 PM · Restricted Project
greened added a comment to D58548: IR: Support parsing numeric block ids, and emit them in textual output..

+1. Is there any reason not to use "%4" in the definition?

Feb 22 2019, 11:30 AM · Restricted Project, Restricted Project
greened created D58546: [lit] Honor PYTHONPATH for llvm tests.
Feb 22 2019, 7:22 AM · Restricted Project

Feb 11 2019

greened committed rG5caa55064974: Add recipes for migrating downstream branches of git mirrors (authored by greened).
Add recipes for migrating downstream branches of git mirrors
Feb 11 2019, 7:40 AM
greened committed rL353713: Add recipes for migrating downstream branches of git mirrors.
Add recipes for migrating downstream branches of git mirrors
Feb 11 2019, 7:40 AM
greened closed D56550: Add recipes for migrating downstream branches of git mirrors.
Feb 11 2019, 7:40 AM · Restricted Project

Feb 7 2019

greened added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

We've already agreed that the unit of the vlen parameter is just the element type (that is the sub-vector element type in the vector-of-subvector interpretation of scalable types).

appreciated, simoll, apologies for giving the false impression that there was disagreement with that: i remained silent previously, as i agreed with the conclusion / logic, that vlen should match the full total number elements even on sub-vectors.

i *believe* (robin, can you clarify / confirm?) that robin may have been disagreeing on predicate masks, i.e. i *believe* that robin may be requesting that predicate masks *also* match the elements one-for-one. in SV, as jacob expressed: we definitely feel that an option for predicates to be on the *sub-vectors* i.e. len(predicate_mask) == VL/VSCALE (*not* just VL) would result in much more optimal SV-assembler being generated.

Feb 7 2019, 11:11 AM · Restricted Project

Feb 4 2019

greened added inline comments to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.
Feb 4 2019, 10:52 AM · Restricted Project

Jan 31 2019

greened added inline comments to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.
Jan 31 2019, 10:56 AM · Restricted Project

Jan 29 2019

greened updated the diff for D56550: Add recipes for migrating downstream branches of git mirrors.

Note important considerations with respect to upstream merges after zipping.

Jan 29 2019, 8:15 AM · Restricted Project
greened updated the diff for D56550: Add recipes for migrating downstream branches of git mirrors.

Added --source-kind=split to the migrate-downstream-fork.py example.

Jan 29 2019, 8:03 AM · Restricted Project

Jan 28 2019

greened updated the diff for D56550: Add recipes for migrating downstream branches of git mirrors.

Fix typos

Jan 28 2019, 12:45 PM · Restricted Project
greened updated the diff for D56550: Add recipes for migrating downstream branches of git mirrors.

Updated for new and improved zipping tool.

Jan 28 2019, 12:42 PM · Restricted Project

Jan 10 2019

greened updated the diff for D56550: Add recipes for migrating downstream branches of git mirrors.

Updated with blessed monorepo URL.

Jan 10 2019, 12:58 PM · Restricted Project
greened added inline comments to D56550: Add recipes for migrating downstream branches of git mirrors.
Jan 10 2019, 12:54 PM · Restricted Project
greened updated the diff for D56550: Add recipes for migrating downstream branches of git mirrors.

Fixed more typos.

Jan 10 2019, 12:53 PM · Restricted Project
greened added a comment to D56550: Add recipes for migrating downstream branches of git mirrors.

Oh yes, it's 100% the most likely scenario for downstream forks with history (e.g. shared internally to others in their org). But what I mean is that there's a lot of individual developers with their own private work-in-progress local *UNSHARED* repositories and checkouts, which will likely have no (important/intentional) merge commits because they're just working on patches to submit upstream.

Those migrations are going to be the most common, and such people shouldn't think they need to use these migration tools when a simple git rebase or format-patch/apply would likely be more appropriate.

Jan 10 2019, 10:55 AM · Restricted Project
greened updated the diff for D56550: Add recipes for migrating downstream branches of git mirrors.

Fixed various typos.

Jan 10 2019, 10:52 AM · Restricted Project
greened added a comment to D56550: Add recipes for migrating downstream branches of git mirrors.

Do a lot of people use the old monorepo for development? We don't so I haven't developed any process for migrating from that. I'll leave that to someone else to add.

Jan 10 2019, 10:30 AM · Restricted Project
greened added inline comments to D56550: Add recipes for migrating downstream branches of git mirrors.
Jan 10 2019, 10:24 AM · Restricted Project
greened added a comment to D56550: Add recipes for migrating downstream branches of git mirrors.

I could certainly put these instructions in a separate document, but where should it go? This is a one-time operation and so it doesn't make sense to put it in with the regular LLVM docs. It's not a proposal, per se, so I don't think it belongs in docs/Proposals other than as an addition to a related proposal, which is this document.

Jan 10 2019, 10:23 AM · Restricted Project
greened added inline comments to D56550: Add recipes for migrating downstream branches of git mirrors.
Jan 10 2019, 10:21 AM · Restricted Project
greened updated the diff for D56550: Add recipes for migrating downstream branches of git mirrors.

Noted that when zipping, and non-LLVM repositories added as submodules need to be imported into the monorepo.

Jan 10 2019, 10:19 AM · Restricted Project
greened added reviewers for D56550: Add recipes for migrating downstream branches of git mirrors: fedor.sergeev, danilaml, chapuni, bjope, rnk.
Jan 10 2019, 8:58 AM · Restricted Project
greened added a comment to D53414: Add instructions for migrating branches from one git repository to another..

I created some instructions in D56550 which should cover the most common cases.

Jan 10 2019, 8:56 AM
greened created D56550: Add recipes for migrating downstream branches of git mirrors.
Jan 10 2019, 8:56 AM · Restricted Project

Jan 9 2019

greened added a comment to D53414: Add instructions for migrating branches from one git repository to another..

As @bogner mentioned, the last section (Multirepo to Monorepo, With Merges) is almost certainly the most common downstream situation. I may write up some recipes under this header and move it to a more prominent position in a separate patch. The discussion of the other situations is orthogonal to the kinds of things I found I needed to do downstream.

Jan 9 2019, 2:18 PM
greened added a comment to D53414: Add instructions for migrating branches from one git repository to another..

What's the status of this? Since the monorepo prototype seems very likely to be blessed soon, I was thinking of writing up some recipes for common downstream migrations. This document would seem to be the right place to put them but it seems from all the comments that this is very much in flux.

Jan 9 2019, 1:07 PM

Jan 7 2019

greened added inline comments to D55758: [TableGen] : Extend !if semantics through new language feature !ifs.
Jan 7 2019, 10:03 AM
greened updated the diff for D49672: [CMake] Honor LLVM_EXTERNAL_<proj>_SOURCE_DIR.

Better handle clang-tools-extra too.

Jan 7 2019, 9:10 AM · Restricted Project
greened updated the diff for D49672: [CMake] Honor LLVM_EXTERNAL_<proj>_SOURCE_DIR.

Updated to use CACHE_STRING as suggested.

Jan 7 2019, 9:08 AM · Restricted Project
greened closed D50388: Respect PYTHONPATH.
Jan 7 2019, 8:59 AM
greened added a comment to D50388: Respect PYTHONPATH.

Committed in r350536.

Jan 7 2019, 8:59 AM
greened committed rL350536: [lit] Respect PYTHONPATH.
[lit] Respect PYTHONPATH
Jan 7 2019, 8:28 AM
greened added inline comments to D56244: [XRay][docs] XRay Framework Usage Guide.
Jan 7 2019, 7:58 AM

Jan 6 2019

greened added a comment to D56266: [GlobalISel] Fix choice of instruction selector for AArch64 at -O0 with -global-isel=0.

This also looks fine to me but I'm in the same boat as Jonas when it comes to (non-)knowledge of GlobalISel.

Jan 6 2019, 7:43 PM
greened added a comment to D53613: RFC: Explicit Vector Length Intrinsics and Attributes.

It's still just an intrinsic so i do not see how transformations that only look at Instruction and don't dig deeper could break the EVL intrinsic call.

Jan 6 2019, 7:03 PM · Restricted Project

Jan 4 2019

greened added a comment to D56202: [OpenMP] Remove -fno-experimental-isel from OMP testing.

No, I haven't implemented `frameaddress` or done any GISel work at all. From our ML conversation, I was under the impression that the tests didn't need `-fno-experimental-isel`` anymore.

Jan 4 2019, 11:29 AM · Restricted Project

Jan 2 2019

greened added a comment to D50388: Respect PYTHONPATH.

Ping?

Jan 2 2019, 10:46 AM
greened created D56202: [OpenMP] Remove -fno-experimental-isel from OMP testing.
Jan 2 2019, 8:23 AM · Restricted Project

Dec 21 2018

greened added a comment to D53613: RFC: Explicit Vector Length Intrinsics and Attributes.

What are the semantics for a call that doesn't have a passthrough attribute? For disabled lanes what's the expected output value? I hope it's undef.

Dec 21 2018, 2:09 PM · Restricted Project
greened added a comment to D53613: RFC: Explicit Vector Length Intrinsics and Attributes.

You can now, as in the PredicatedVectorType proposal, switch transformations/anslysis from BinaryOperator to PredicatedBinaryOperator one at a time.
In fact, if this is executed properly it doesn't actually matter that much anymore whether we use intrinsics or predicated core instructions... and so PredicatedVectorType is obsolete.

Dec 21 2018, 2:02 PM · Restricted Project
greened added a comment to D53613: RFC: Explicit Vector Length Intrinsics and Attributes.

@simoll
Sorry, I'm joining this conversation late.

Dec 21 2018, 8:32 AM · Restricted Project

Nov 13 2018

greened added a comment to D53770: Support g++ headers in include/g++.

Oops, I didn't realize this hadn't been formally accepted yet. Still learning the Phab process. Let me know if you want it reverted for a formal accept.

Nov 13 2018, 1:42 PM
greened committed rC346802: [Driver] Support g++ headers in include/g++.
[Driver] Support g++ headers in include/g++
Nov 13 2018, 1:41 PM
greened committed rL346802: [Driver] Support g++ headers in include/g++.
[Driver] Support g++ headers in include/g++
Nov 13 2018, 1:41 PM