Page MenuHomePhabricator

GMNGeoffrey (Geoffrey Martin-Noble)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 15 2020, 6:41 PM (52 w, 5 d)

Recent Activity

Sat, Jan 16

GMNGeoffrey added a comment to D94451: Proposal for allowing unsupported build system configuration in-tree.

[snip]

I feel like we've been side-tracked by meta-arguments a lot in this discussion, so I'm going to make a few points and hopefully try to wrap this up.

Sat, Jan 16, 9:40 AM

Fri, Jan 15

GMNGeoffrey added a comment to D94451: Proposal for allowing unsupported build system configuration in-tree.

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

OK, I think it would be better if this pitch was about adding bazel specifically. I don't really see what having a generic "unsupported build system" pitch gains us, when the specific build systems will all still need to go through the RFC process.

So I must confess that I'm a bit frustrated by this comment, Tom. The reason I'm writing this as a pitch is because the RFC(s) I wrote were determined to be "controversial" even after we had a support policy that explicitly discussed build systems. As far as I can tell, none of the objections raised that made it controversial had to do with Bazel in particular or whether its addition could satisfy the requirements of the support policy, but rather had to do with adding unsupported build systems in general. That was surprising to me, since we'd just had a separate RFC for a support policy, which seems like it would have been the ideal time to raise such objections, but people made the reasonable argument that the writing of that policy was very new (although the policies it recorded were not) and the inclusion of build configurations might reasonably have been missed when people were reviewing it. The prevailing view on the thread seemed to be we should escalate the point about unsupported build systems to come to a decision. So in my mind, this pitch is to make explicit and allow further discussion on the inclusion of unsupported build systems in the support policy, whereas before it was just a sentence that mentioned them as an example. I'm sympathetic to that and don't want to be just slipping things through, but I'd also like to actually make progress here and I feel like we have entered exactly the situation you've described as being opposed to when requesting that we escalate to a pitch: that is a "battle of attrition". I think you've raised reasonable concerns about build system proliferation, and I think we should discuss them, but I'm not sure how me writing yet another iteration of this proposal actually helps us here.

I guess I'm fine making this proposal "Unsupported build systems are allowed and Bazel is, in particular", so we don't have to then do yet another RFC, but my plan was to just reopen the previous RFC and return to the issues of Bazel in particular (and even more specifically our implementation of the LLVM config for it, which I think there were some reasonable criticisms of). I'm worried that discussing the specific case means that if some poor soul wants to add, say, a Meson build or whatever they will have to relitigate these points that have already been decided.

Can you understand where I'm coming from here?

Yes, and I think there may be some misunderstanding here, because the main reason I suggested you include Bazel in this pitch was to try to save your time and energy.

When I first suggested doing a pitch, my assumption was that the RFC for Bazel would turn into a pitch for Bazel and that would be it, however if we proceed with this pitch as written, then we would have had 2 RFCs, 1 Pitch, and still no final decision about Bazel. This seems to me like much more work then what we need to do, not to mention the fact that it is very confusing, and I don't think it's really fair to expect people who object to the original RFC to keep objecting to all these new proposals.

Fri, Jan 15, 6:47 PM
GMNGeoffrey added a comment to D94451: Proposal for allowing unsupported build system configuration in-tree.

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

OK, I think it would be better if this pitch was about adding bazel specifically. I don't really see what having a generic "unsupported build system" pitch gains us, when the specific build systems will all still need to go through the RFC process.

Fri, Jan 15, 5:09 PM

Wed, Jan 13

GMNGeoffrey added inline comments to D94451: Proposal for allowing unsupported build system configuration in-tree.
Wed, Jan 13, 9:33 AM
GMNGeoffrey updated the diff for D94451: Proposal for allowing unsupported build system configuration in-tree.
  • Fix typos
Wed, Jan 13, 9:32 AM
GMNGeoffrey added reviewers for D94451: Proposal for allowing unsupported build system configuration in-tree: rengolin, beanz, tstellar, echristo, lattner.
Wed, Jan 13, 9:30 AM
GMNGeoffrey added a comment to D94451: Proposal for allowing unsupported build system configuration in-tree.

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

Wed, Jan 13, 9:29 AM

Mon, Jan 11

GMNGeoffrey updated the diff for D94451: Proposal for allowing unsupported build system configuration in-tree.
  • Add links to pitch thread now that it exists
Mon, Jan 11, 2:17 PM
GMNGeoffrey updated the summary of D94451: Proposal for allowing unsupported build system configuration in-tree.
Mon, Jan 11, 2:15 PM
GMNGeoffrey requested review of D94451: Proposal for allowing unsupported build system configuration in-tree.
Mon, Jan 11, 2:11 PM

Dec 15 2020

GMNGeoffrey updated the summary of D93358: Remove erroneous trailing comma in arcconfig.
Dec 15 2020, 4:53 PM
GMNGeoffrey added a reviewer for D93358: Remove erroneous trailing comma in arcconfig: mehdi_amini.
Dec 15 2020, 4:51 PM
GMNGeoffrey requested review of D93358: Remove erroneous trailing comma in arcconfig.
Dec 15 2020, 4:50 PM

Nov 19 2020

GMNGeoffrey committed rG0f9f0a4046e1: Remove unused isZero function (authored by GMNGeoffrey).
Remove unused isZero function
Nov 19 2020, 7:59 PM
GMNGeoffrey closed D91838: Remove unused isZero function.
Nov 19 2020, 7:59 PM · Restricted Project
GMNGeoffrey updated the summary of D91838: Remove unused isZero function.
Nov 19 2020, 7:37 PM · Restricted Project
GMNGeoffrey retitled D91838: Remove unused isZero function from Remove unused function to Remove unused isZero function.
Nov 19 2020, 7:37 PM · Restricted Project
GMNGeoffrey retitled D91838: Remove unused isZero function from Remove unused function Unused since https://reviews.llvm.org/D91503 and triggering -Wunused-function to Remove unused function.
Nov 19 2020, 7:37 PM · Restricted Project
GMNGeoffrey added a comment to D91503: [mlir][Linalg] Expose some utility functions used for promotion..

FYI this leaves an unused function

Nov 19 2020, 7:36 PM · Restricted Project
GMNGeoffrey requested review of D91838: Remove unused isZero function.
Nov 19 2020, 7:36 PM · Restricted Project
GMNGeoffrey committed rGb156514f8d99: Remove unused private fields (authored by GMNGeoffrey).
Remove unused private fields
Nov 19 2020, 1:55 PM
GMNGeoffrey closed D91820: Remove unused private fields.
Nov 19 2020, 1:55 PM · Restricted Project
GMNGeoffrey added a comment to D91762: [dfsan] Remove deadcode from DFSanFunction::get*TLS*().

FYI this results in unused private fields which causes diagnostic errors for -Wunused-private-field.

llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp:365:13: error: private field 'GetArgTLS' is not used [-Werror,-Wunused-private-field]
  Constant *GetArgTLS;
            ^
llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp:366:13: error: private field 'GetRetvalTLS' is not used [-Werror,-Wunused-private-field]
  Constant *GetRetvalTLS;
Nov 19 2020, 1:40 PM · Restricted Project
GMNGeoffrey added reviewers for D91820: Remove unused private fields: stephan.yichao.zhao, morehouse.
Nov 19 2020, 1:36 PM · Restricted Project
GMNGeoffrey requested review of D91820: Remove unused private fields.
Nov 19 2020, 1:36 PM · Restricted Project
GMNGeoffrey added a comment to D91762: [dfsan] Remove deadcode from DFSanFunction::get*TLS*().

FYI this results in unused private fields which causes diagnostic errors for -Wunused-private-field.

Nov 19 2020, 1:31 PM · Restricted Project

Nov 16 2020

GMNGeoffrey updated the diff for D90352: Introduce a Bazel build configuration.
  • Add coverage info and usage instructions
Nov 16 2020, 5:40 PM · Restricted Project
GMNGeoffrey updated the diff for D90352: Introduce a Bazel build configuration.
  • Add README
  • Pull in new changes from llvm-bazel repository
Nov 16 2020, 4:48 PM · Restricted Project

Nov 12 2020

GMNGeoffrey added a comment to D91013: [docs] link new support policy from developer policy.

Thanks for adding this Renato :-) I was out the first part of this week, but LGTM

Nov 12 2020, 10:47 AM · Restricted Project

Nov 6 2020

GMNGeoffrey accepted D90761: [docs] Adding a Support Policy.

LGTM, but please wait for others' review, obviously :-)

Nov 6 2020, 11:52 AM · Restricted Project

Nov 5 2020

GMNGeoffrey added inline comments to D90761: [docs] Adding a Support Policy.
Nov 5 2020, 2:01 PM · Restricted Project

Nov 4 2020

GMNGeoffrey added a comment to D90761: [docs] Adding a Support Policy.

Overall LGTM, with some wording nits. One thing I think is missing is guidance for how a peripheral component gets added. Experimental targets already have their own documentation, and my impression is that editor bindings are just a matter of sending a patch (which seems reasonable to me). What about something like:

Nov 4 2020, 12:36 PM · Restricted Project

Oct 30 2020

GMNGeoffrey added a reverting change for rG27324f28552d: [MLIR][SPIRV] Start module combiner.: rG1142eaed9d4e: Revert "[MLIR][SPIRV] Start module combiner.".
Oct 30 2020, 1:35 PM
GMNGeoffrey committed rG1142eaed9d4e: Revert "[MLIR][SPIRV] Start module combiner." (authored by GMNGeoffrey).
Revert "[MLIR][SPIRV] Start module combiner."
Oct 30 2020, 1:35 PM
GMNGeoffrey added a comment to D90477: [MLIR][SPIRV] Start module combiner..

https://github.com/llvm/llvm-project/commit/1142eaed9d4e31aa10584f2755a350970495002f reverts

Oct 30 2020, 1:35 PM · Restricted Project
GMNGeoffrey added a reverting change for D90477: [MLIR][SPIRV] Start module combiner.: rG1142eaed9d4e: Revert "[MLIR][SPIRV] Start module combiner.".
Oct 30 2020, 1:35 PM · Restricted Project
GMNGeoffrey added a comment to D90477: [MLIR][SPIRV] Start module combiner..

FYI this breaks the build with shared libs https://buildkite.com/mlir/mlir-core/builds/8988#e3d966b9-ea43-492e-a192-b28e71e9a15b. I'm investigating a fix.

Oops. Thanks Geoffrey! If it's not trivial, feel free to revert.

Oct 30 2020, 1:29 PM · Restricted Project
GMNGeoffrey added a comment to D90477: [MLIR][SPIRV] Start module combiner..

FYI this breaks the build with shared libs https://buildkite.com/mlir/mlir-core/builds/8988#e3d966b9-ea43-492e-a192-b28e71e9a15b. I'm investigating a fix.

Oct 30 2020, 1:27 PM · Restricted Project
GMNGeoffrey added a comment to D90477: [MLIR][SPIRV] Start module combiner..

FYI this breaks the build with shared libs https://buildkite.com/mlir/mlir-core/builds/8988#e3d966b9-ea43-492e-a192-b28e71e9a15b. I'm investigating a fix.

Oct 30 2020, 1:12 PM · Restricted Project

Oct 29 2020

GMNGeoffrey added a comment to D90352: Introduce a Bazel build configuration.

Could you add something similar to https://github.com/llvm/llvm-project/blob/master/llvm/utils/gn/README.rst?

  • How to build something?
  • How to use clang/llvm/mlir as an external dependency?
Oct 29 2020, 11:40 AM · Restricted Project

Oct 28 2020

GMNGeoffrey updated the summary of D90352: Introduce a Bazel build configuration.
Oct 28 2020, 4:23 PM · Restricted Project
GMNGeoffrey requested review of D90352: Introduce a Bazel build configuration.
Oct 28 2020, 4:06 PM · Restricted Project

Oct 26 2020

GMNGeoffrey added a comment to D89758: Unconditionally #include <future>.

Hi Geoffrey,

Apologies for the delayed reply. Can you share details of the failure
you're seeing?

Regards,
Lang.

Oct 26 2020, 2:39 PM · Restricted Project

Oct 24 2020

GMNGeoffrey added a comment to D89142: llvmbuildectomy.

How about keeping the Bazel files in-tree?

  • more customers
  • better visibility
  • lower maintenance costs
  • ...
Oct 24 2020, 1:25 PM · Restricted Project

Oct 23 2020

GMNGeoffrey updated the diff for D89758: Unconditionally #include <future>.

Rebase on master again

Oct 23 2020, 10:36 AM · Restricted Project

Oct 20 2020

GMNGeoffrey committed rGc17ae2916ccf: Remove unnecessary header include which violates layering (authored by GMNGeoffrey).
Remove unnecessary header include which violates layering
Oct 20 2020, 8:14 PM
GMNGeoffrey closed D89843: Remove unnecessary header include which violates layering.
Oct 20 2020, 8:14 PM · Restricted Project
GMNGeoffrey added a comment to D89843: Remove unnecessary header include which violates layering.

Landing with failed builds. Looks like the same test is failing at HEAD: https://buildkite.com/llvm-project/llvm-master-build/builds/1281#df0e1b85-07a8-4199-8c41-79b6b38bd099

Oct 20 2020, 8:12 PM · Restricted Project
GMNGeoffrey added a reviewer for D89843: Remove unnecessary header include which violates layering: aeubanks.
Oct 20 2020, 7:41 PM · Restricted Project
GMNGeoffrey updated the summary of D89843: Remove unnecessary header include which violates layering.
Oct 20 2020, 7:39 PM · Restricted Project
GMNGeoffrey updated the diff for D89843: Remove unnecessary header include which violates layering.

Update commit message

Oct 20 2020, 7:39 PM · Restricted Project
GMNGeoffrey added a reviewer for D89843: Remove unnecessary header include which violates layering: TaWeiTu.
Oct 20 2020, 7:38 PM · Restricted Project
GMNGeoffrey updated the summary of D89843: Remove unnecessary header include which violates layering.
Oct 20 2020, 7:37 PM · Restricted Project
GMNGeoffrey requested review of D89843: Remove unnecessary header include which violates layering.
Oct 20 2020, 7:36 PM · Restricted Project
GMNGeoffrey added a comment to D89758: Unconditionally #include <future>.

Hmmm seems this breaks lld on windows somehow... @lhames could you investigate a more principled fix? I think the approach of providing an alternative implementation if LLVM_ENABLE_THREADS is false would be consistent with other places in the file

Oct 20 2020, 5:31 PM · Restricted Project
GMNGeoffrey updated the diff for D89758: Unconditionally #include <future>.

Rebase on master

Oct 20 2020, 10:36 AM · Restricted Project

Oct 19 2020

GMNGeoffrey committed rGad0b2d9d46a3: Add llvm_unreachable to avoid MSVC warning (authored by GMNGeoffrey).
Add llvm_unreachable to avoid MSVC warning
Oct 19 2020, 8:29 PM
GMNGeoffrey closed D89760: Add llvm_unreachable to avoid MSVC warning.
Oct 19 2020, 8:29 PM · Restricted Project
GMNGeoffrey updated the diff for D89760: Add llvm_unreachable to avoid MSVC warning.
  • Improve error message
Oct 19 2020, 8:11 PM · Restricted Project
GMNGeoffrey added a comment to D89758: Unconditionally #include <future>.

We've been building with LLVM_ENABLE_THREADS=0 to avoid dependencies on the TLS support in the build environment. We may require assistance to restore our builds if these patches introduce a TLS dependency. @daltenty, fyi.

Oct 19 2020, 8:08 PM · Restricted Project
GMNGeoffrey added a reviewer for D89760: Add llvm_unreachable to avoid MSVC warning: rriddle.
Oct 19 2020, 7:21 PM · Restricted Project
GMNGeoffrey requested review of D89760: Add llvm_unreachable to avoid MSVC warning.
Oct 19 2020, 7:20 PM · Restricted Project
GMNGeoffrey added a comment to D89758: Unconditionally #include <future>.

Note that I'm not familiar with this part of the codebase, so if there's a better fix (like we can add a guard to the std::promise usage) then I'm happy to do that instead. I'm just trying to maintain a LLVM_ENABLE_THREADS=0 build because of https://bugs.llvm.org/show_bug.cgi?id=44211.

Oct 19 2020, 7:17 PM · Restricted Project
GMNGeoffrey updated the summary of D89758: Unconditionally #include <future>.
Oct 19 2020, 7:10 PM · Restricted Project
GMNGeoffrey added a reviewer for D89758: Unconditionally #include <future>: lhames.
Oct 19 2020, 7:09 PM · Restricted Project
GMNGeoffrey requested review of D89758: Unconditionally #include <future>.
Oct 19 2020, 7:09 PM · Restricted Project

Oct 16 2020

GMNGeoffrey accepted D89593: [mlir] Failure when const matcher fails, added a test to catch.
Oct 16 2020, 2:14 PM · Restricted Project

Oct 15 2020

GMNGeoffrey accepted D89516: [MLIR] Fix gcc5 in D89161.

Thanks!

Oct 15 2020, 5:02 PM · Restricted Project

Oct 13 2020

GMNGeoffrey committed rGb49787df9a53: Remove unused SideEffectInterfaces header (authored by GMNGeoffrey).
Remove unused SideEffectInterfaces header
Oct 13 2020, 3:26 PM
GMNGeoffrey closed D89347: Remove unused SideEffectInterfaces header.
Oct 13 2020, 3:26 PM · Restricted Project
GMNGeoffrey added reviewers for D89347: Remove unused SideEffectInterfaces header: mehdi_amini, ahmedsabie.
Oct 13 2020, 3:22 PM · Restricted Project
GMNGeoffrey requested review of D89347: Remove unused SideEffectInterfaces header.
Oct 13 2020, 3:22 PM · Restricted Project

Oct 10 2020

GMNGeoffrey added a comment to D89142: llvmbuildectomy.

Wow pretty neat to see llvmbuild being removed!

That said we are still depending on it (we generate Bazel build file from this and use this in many projects using MLIR like TensorFlow, XLA, IREE...).
We need to move away from it: can you ping me and/or @GMNGeoffrey when you get closer to have this in a landing state?

Could the generation of Bazel files be done by parsing the compile_commands.json maybe? that seems like a more "portable" approach since it's a pretty standard format these days.

Oct 10 2020, 6:47 PM · Restricted Project

Oct 7 2020

GMNGeoffrey added a comment to D89022: Remove unused variables.

Committed as https://github.com/llvm/llvm-project/commit/93db4a8ce6261dc36e233f5e0b60cfbb3ea1bd8f

Oct 7 2020, 6:32 PM · Restricted Project
GMNGeoffrey added a comment to D87148: [ImplicitNullCheck] Handle Nonzero faulting pages and complex addressing.

Hey JFYI this created some unused variables. I fixed with https://reviews.llvm.org/D89022

Oct 7 2020, 6:31 PM · Restricted Project
GMNGeoffrey committed rG93db4a8ce626: Remove unused variables (authored by GMNGeoffrey).
Remove unused variables
Oct 7 2020, 6:30 PM
GMNGeoffrey closed D89022: Remove unused variables.
Oct 7 2020, 6:30 PM · Restricted Project
GMNGeoffrey requested review of D89022: Remove unused variables.
Oct 7 2020, 6:25 PM · Restricted Project

Sep 30 2020

GMNGeoffrey updated the diff for D88530: Remove `Ops` suffix from dialect library names.
  • Fix flang
Sep 30 2020, 11:20 AM · Restricted Project
GMNGeoffrey abandoned D88596: Remove `Ops` suffix from dialect library names.

Whoops meant to upload a patch to an existing revision

Sep 30 2020, 10:27 AM · Restricted Project
GMNGeoffrey requested review of D88596: Remove `Ops` suffix from dialect library names.
Sep 30 2020, 10:26 AM · Restricted Project
GMNGeoffrey added a comment to D88530: Remove `Ops` suffix from dialect library names.

Oh huh, I broke flang :-D I was just replacing in the MLIR directory

Sep 30 2020, 10:23 AM · Restricted Project
GMNGeoffrey added inline comments to D88530: Remove `Ops` suffix from dialect library names.
Sep 30 2020, 10:22 AM · Restricted Project

Sep 29 2020

GMNGeoffrey added inline comments to D88530: Remove `Ops` suffix from dialect library names.
Sep 29 2020, 11:11 PM · Restricted Project
GMNGeoffrey requested review of D88530: Remove `Ops` suffix from dialect library names.
Sep 29 2020, 11:04 PM · Restricted Project

Sep 10 2020

GMNGeoffrey added a comment to D87177: Add more explicit error message when creating a type or attribute for an unregistered dialect (NFC).

Thanks for improving error messages Mehdi!

Sep 10 2020, 11:29 AM · Restricted Project

Sep 3 2020

GMNGeoffrey added inline comments to D86392: Implement a new kind of Pass: dynamic pass pipeline.
Sep 3 2020, 9:49 AM · Restricted Project

Sep 2 2020

GMNGeoffrey added a comment to D86892: Improve error handling for SmallVector programming errors..

Thanks for reviewing!

Sep 2 2020, 3:00 PM · Restricted Project
GMNGeoffrey updated the diff for D86892: Improve error handling for SmallVector programming errors..

Drop NOLINTNEXTLINE

Sep 2 2020, 2:59 PM · Restricted Project
GMNGeoffrey added a comment to D86892: Improve error handling for SmallVector programming errors..

If y'all are good with this now (and think that others will not have objects), could one of you land it for me? I don't have commit access.

Will do:) You can drop NOLINTNEXTLINE(readability-identifier-naming). The issues are known and are everywhere... Just ignore them and don't bother annotating the code...

Sep 2 2020, 2:56 PM · Restricted Project
GMNGeoffrey updated the summary of D86892: Improve error handling for SmallVector programming errors..
Sep 2 2020, 2:54 PM · Restricted Project
GMNGeoffrey added a comment to D86892: Improve error handling for SmallVector programming errors..

If y'all are good with this now (and think that others will not have objects), could one of you land it for me? I don't have commit access.

Sep 2 2020, 2:53 PM · Restricted Project
GMNGeoffrey updated the diff for D86892: Improve error handling for SmallVector programming errors..

Use #else after throwing exception

Sep 2 2020, 2:51 PM · Restricted Project
GMNGeoffrey updated the diff for D86892: Improve error handling for SmallVector programming errors..

Suppress pre-existing clang-tidy warnings

Sep 2 2020, 2:16 PM · Restricted Project

Sep 1 2020

GMNGeoffrey updated the diff for D86892: Improve error handling for SmallVector programming errors..

And one more typo...

Sep 1 2020, 4:57 PM · Restricted Project
GMNGeoffrey updated the diff for D86892: Improve error handling for SmallVector programming errors..

Fix typo

Sep 1 2020, 4:56 PM · Restricted Project
GMNGeoffrey added inline comments to D86892: Improve error handling for SmallVector programming errors..
Sep 1 2020, 4:55 PM · Restricted Project
GMNGeoffrey updated the diff for D86892: Improve error handling for SmallVector programming errors..

Fix lint. Switch to explicit const char *

Sep 1 2020, 4:55 PM · Restricted Project
GMNGeoffrey added inline comments to D86915: Use an Identifier instead of an OperationName internally for OpPassManager identification (NFC).
Sep 1 2020, 9:56 AM · Restricted Project
GMNGeoffrey accepted D86915: Use an Identifier instead of an OperationName internally for OpPassManager identification (NFC).

Thanks!

Sep 1 2020, 9:48 AM · Restricted Project