Page MenuHomePhabricator

zero9178 (Markus Böck)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 14 2019, 12:14 PM (150 w, 6 d)

Recent Activity

Today

zero9178 committed rG73440ca9f878: [mlir] Define proper DenseMapInfo for Interfaces (authored by zero9178).
[mlir] Define proper DenseMapInfo for Interfaces
Wed, Jul 6, 3:39 AM · Restricted Project, Restricted Project
zero9178 added inline comments to D129038: [mlir] Define proper DenseMapInfo for Interfaces.
Wed, Jul 6, 3:39 AM · Restricted Project, Restricted Project
zero9178 closed D129038: [mlir] Define proper DenseMapInfo for Interfaces.
Wed, Jul 6, 3:39 AM · Restricted Project, Restricted Project

Yesterday

zero9178 committed rGf2beca908d4e: [mlir][tblgen] Consistently use `$_ctxt` instead of `$_ctx` (authored by zero9178).
[mlir][tblgen] Consistently use `$_ctxt` instead of `$_ctx`
Tue, Jul 5, 11:15 AM · Restricted Project, Restricted Project
zero9178 closed D129153: [mlir][tblgen] Consistently use `$_ctxt` instead of `$_ctx`.
Tue, Jul 5, 11:14 AM · Restricted Project, Restricted Project
zero9178 requested review of D129153: [mlir][tblgen] Consistently use `$_ctxt` instead of `$_ctx`.
Tue, Jul 5, 10:43 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D129038: [mlir] Define proper DenseMapInfo for Interfaces.

Address review comments: Explicitly put DenseMapInfo specialization into the llvm namespace

Tue, Jul 5, 8:40 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D129038: [mlir] Define proper DenseMapInfo for Interfaces.

Address review comments

Tue, Jul 5, 8:17 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D129038: [mlir] Define proper DenseMapInfo for Interfaces.

Add tests for attribute and type interfaces as well.

Tue, Jul 5, 7:48 AM · Restricted Project, Restricted Project
zero9178 added inline comments to D129038: [mlir] Define proper DenseMapInfo for Interfaces.
Tue, Jul 5, 7:39 AM · Restricted Project, Restricted Project
zero9178 added inline comments to D129038: [mlir] Define proper DenseMapInfo for Interfaces.
Tue, Jul 5, 7:04 AM · Restricted Project, Restricted Project
zero9178 retitled D129038: [mlir] Define proper DenseMapInfo for Interfaces from [mlir][tblgen] Generate proper DenseMapInfo for Interfaces to [mlir] Define proper DenseMapInfo for Interfaces.
Tue, Jul 5, 2:23 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D129038: [mlir] Define proper DenseMapInfo for Interfaces.

Change approach to using SFINAE to pick the correct template specialization. This sadly requires an intrusive change of the DenseMapInfo specializations of OpState, Type and Attribute to avoid an ambiguity of template specializations.

Tue, Jul 5, 2:20 AM · Restricted Project, Restricted Project

Sun, Jul 3

zero9178 updated the diff for D129038: [mlir] Define proper DenseMapInfo for Interfaces.
  • Use a macro to define the llvm::DefineMapInfo specialization. That way, handwritten interfaces can easily make use of it as well.
  • Add some special code that checks that the interface declarations are being included in the global namespace. Pros of this approach:
    • Just a tiny bit of extra code
    • A proper static_assert which can output a custom error that is as detailed as we want it to be Cons:
    • The code is odd imho.
    • Polluting the global namespace with MLIR_TEST_GLOBAL_NAMESPACE_INCLUDE (albeit it's named like a macro, hence not as big of a deal)
Sun, Jul 3, 3:58 AM · Restricted Project, Restricted Project

Sat, Jul 2

zero9178 added inline comments to D129038: [mlir] Define proper DenseMapInfo for Interfaces.
Sat, Jul 2, 7:50 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D129038: [mlir] Define proper DenseMapInfo for Interfaces.

Fix examples build

Sat, Jul 2, 7:24 AM · Restricted Project, Restricted Project
zero9178 requested review of D129038: [mlir] Define proper DenseMapInfo for Interfaces.
Sat, Jul 2, 5:21 AM · Restricted Project, Restricted Project

Thu, Jun 16

zero9178 added a comment to D127952: [mlir] replace 'emit_c_wrappers' func->llvm conversion option with a pass.

I went for the least worst solution here. FuncTransforms library already depends on "higher level" dialects (SCF, MemRef and co.), adding the "lower level" dialect sounds undesirable. LLVMTransforms, on the other hand, can have a dependency on the "higher level" Func dialect and be consistent. (Note that there is no dependency between dialects themselves.)

The attribute is only relevant for the func->llvm conversion, so the independent place for it would be somewhere in lib/Conversions/FuncToLLVM/AdditionalPasses, but that would be a significant architectural change, even though with a small amount of code. Making it into an operation pass will allow the attribute to be attached to any operation, where it doesn't make sense and will be confusing. As for some hypothetical other dialect that may want this, I would rather not overgeneralize prematurely. When and if this dialect appears, we can reconsider. FWIW, the only reason the pass is introduced is some backwards compatibility for downstreams that may depend on this behavior to be configurable from the textual pass pipeline. Otherwise, the code to add the attribute to all functions takes three lines, it can be duplicated at will.

Thu, Jun 16, 12:06 PM · Restricted Project, Restricted Project
zero9178 added a comment to D127952: [mlir] replace 'emit_c_wrappers' func->llvm conversion option with a pass.

Very big fan of this change. That option in particular is very specific to a single scenario (memrefs as arguments), and being able to move it out of a generic options class is a lot cleaner.

The layering here is a bit odd to me however. The way llvm.emit_c_interface is currently implemented, is only applicable to func.func to llvm.func conversions (which is fair), yet the convenience pass to add the llvm.emit_c_wrapper attribute to all functions lives in LLVM Dialect transforms and depends on func.func.
The way I see it either:

  • llvm.emit_c_interface is meant as a general purpose indicator that any dialect may use during type lowering. In that case the pass should probably be a generic operation pass and not only apply to mlir::func::FuncOp. This would also drop the link dependency on MLIRFuncDialect from LLVMIRTransforms
  • llvm.emit_c_interface shouldn't be part of the LLVM dialect but rather of the func dialect. There is currently no code that actually checks llvm.emit_c_interface except in FuncToLLVM.cpp

My two cents on this: I'm not too fond of options one as I don't see many other use cases for the attribute. Option two may have the problem that any pass before conversion to LLVM can or cannot discard the attribute. I believe that's why we want to do that right before conversion to LLVM.

Thu, Jun 16, 5:57 AM · Restricted Project, Restricted Project
zero9178 added a comment to D127952: [mlir] replace 'emit_c_wrappers' func->llvm conversion option with a pass.

Very big fan of this change. That option in particular is very specific to a single scenario (memrefs as arguments), and being able to move it out of a generic options class is a lot cleaner.

Thu, Jun 16, 5:01 AM · Restricted Project, Restricted Project

Jun 1 2022

zero9178 added inline comments to D126706: [CMake] Improve support for ASAN on Windows with MSVC cl & clang-cl.
Jun 1 2022, 2:12 AM · Restricted Project, Restricted Project

May 31 2022

zero9178 added inline comments to D126706: [CMake] Improve support for ASAN on Windows with MSVC cl & clang-cl.
May 31 2022, 2:55 PM · Restricted Project, Restricted Project

May 21 2022

zero9178 added a comment to D125899: [ADT] Add copy constructor to IntervalMap.

If we are implementing a copy constructor now, shouldn't we be following the Rule of 5 (or at least Rule of 3)? In this case that'd mean also implementing the copy assignment operator and ideally move constructor and move assignment operator. This would be especially important if the interval map were to be inside a vector for performance reasons.

May 21 2022, 4:11 AM · Restricted Project, Restricted Project

Apr 25 2022

zero9178 committed rG12a27169535a: [mlir][LLVM] Support opaque pointers in `llvm.mlir.addressof` (authored by zero9178).
[mlir][LLVM] Support opaque pointers in `llvm.mlir.addressof`
Apr 25 2022, 3:23 AM · Restricted Project, Restricted Project
zero9178 closed D124333: [mlir][LLVM] Support opaque pointers in `llvm.mlir.addressof`.
Apr 25 2022, 3:23 AM · Restricted Project, Restricted Project
zero9178 added inline comments to D124333: [mlir][LLVM] Support opaque pointers in `llvm.mlir.addressof`.
Apr 25 2022, 12:42 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D124333: [mlir][LLVM] Support opaque pointers in `llvm.mlir.addressof`.

Address review comments

Apr 25 2022, 12:40 AM · Restricted Project, Restricted Project
zero9178 committed rG34312f1f0c4f: [mlir][LLVM] Support opaque pointers in data layout entries (authored by zero9178).
[mlir][LLVM] Support opaque pointers in data layout entries
Apr 25 2022, 12:15 AM · Restricted Project, Restricted Project
zero9178 closed D124334: [mlir][LLVM] Support opaque pointers in data layout entries.
Apr 25 2022, 12:15 AM · Restricted Project, Restricted Project

Apr 23 2022

zero9178 requested review of D124334: [mlir][LLVM] Support opaque pointers in data layout entries.
Apr 23 2022, 9:49 AM · Restricted Project, Restricted Project
zero9178 requested review of D124333: [mlir][LLVM] Support opaque pointers in `llvm.mlir.addressof`.
Apr 23 2022, 9:36 AM · Restricted Project, Restricted Project

Apr 22 2022

zero9178 accepted D124312: [Driver] Call hasFlag instead of hasArg.

Ouch! Two bugs, and the one in the testsuite covered up the former one. Thank you for noticing.

Apr 22 2022, 5:23 PM · Restricted Project, Restricted Project
zero9178 committed rG8ed2bd1e7465: [mlir][LLVM] Fix `DataLayoutTypeInterface` for opqaue pointers with non-default… (authored by zero9178).
[mlir][LLVM] Fix `DataLayoutTypeInterface` for opqaue pointers with non-default…
Apr 22 2022, 3:12 PM · Restricted Project, Restricted Project
zero9178 committed rGbab3d3778de1: [mlir][LLVM] Fix crash when using opaque pointers in function signatures (authored by zero9178).
[mlir][LLVM] Fix crash when using opaque pointers in function signatures
Apr 22 2022, 3:12 PM · Restricted Project, Restricted Project
zero9178 closed D124290: [mlir][LLVM] Fix `DataLayoutTypeInterface` for opqaue pointers with non-default address space.
Apr 22 2022, 3:12 PM · Restricted Project, Restricted Project
zero9178 closed D124291: [mlir][LLVM] Fix crash when using opaque pointers in function signatures.
Apr 22 2022, 3:12 PM · Restricted Project, Restricted Project
zero9178 requested review of D124291: [mlir][LLVM] Fix crash when using opaque pointers in function signatures.
Apr 22 2022, 12:20 PM · Restricted Project, Restricted Project
zero9178 requested review of D124290: [mlir][LLVM] Fix `DataLayoutTypeInterface` for opqaue pointers with non-default address space.
Apr 22 2022, 11:46 AM · Restricted Project, Restricted Project
zero9178 added a comment to D124153: [CMake] Make omitting CMAKE_BUILD_TYPE an error.

I can also confirm that a Release build is a LOT easier to build than a debug build.

  • Linker OOMs are mainly caused by large object files, both due to code size of unoptimized code and especially due to the extra debug info. Hence the first recommendation in any of the forums when people show a linker OOM is to make sure they're using a release build, if that is what they intended, and to use LLD or Gold (that is a separate topic however)
  • A debug build on Windows using MSVC can take around 70 to roughly 100 GB of storage space, which are always surprising and may also lead to out of disk space errors. Release builds are comparatively just a few Gigabytes. I believe they are also multiply tens of Gigabytes on other OSs
  • Due to object file limits it is actually impossible to build Clang in debug mode when using a MinGW toolchain without building shared libs as the final linked clang executable is larger than 4GB.
Apr 22 2022, 11:39 AM · Restricted Project, Restricted Project

Apr 21 2022

zero9178 committed rG850b2c6b3c73: [mlir] Fix `Region`s `takeBody` method if the region is not empty (authored by zero9178).
[mlir] Fix `Region`s `takeBody` method if the region is not empty
Apr 21 2022, 6:33 AM · Restricted Project, Restricted Project
zero9178 closed D123913: [mlir] Fix `Region`s `takeBody` method if the region is not empty.
Apr 21 2022, 6:33 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D123913: [mlir] Fix `Region`s `takeBody` method if the region is not empty.

Address review comments

Apr 21 2022, 6:32 AM · Restricted Project, Restricted Project
zero9178 added a comment to D124153: [CMake] Make omitting CMAKE_BUILD_TYPE an error.

Are there any numbers as to how much slower an assertion build in Release mode is? I can see some benefits in having assertions turned on if no build type is specified:

  • Assertion failures have nicer error messages in bug reports than segmentation faults caused by violated pre-conditions
  • It could potentially catch miscompiles or similar that would otherwise go unnoticed
Apr 21 2022, 5:13 AM · Restricted Project, Restricted Project
zero9178 added a comment to D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.

Thanks to the both of you for the very thorough review! Very happy with the result :)

Apr 21 2022, 4:46 AM · Restricted Project, Restricted Project
zero9178 committed rGa41aaf166fed: [mlir] Make `Regions`s `cloneInto` multithread-readable (authored by zero9178).
[mlir] Make `Regions`s `cloneInto` multithread-readable
Apr 21 2022, 4:44 AM · Restricted Project, Restricted Project
zero9178 closed D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.
Apr 21 2022, 4:43 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.

Address review comments

Apr 21 2022, 4:42 AM · Restricted Project, Restricted Project

Apr 20 2022

zero9178 updated the diff for D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.

Hoist vector creation out of loop, allowing reuse of capacity of the vector. Performance is now up to parity if not a little better (although in the margin of error):

[markus@dell-xps13 bin]$ hyperfine --prepare 'sleep 20'  './pylir-opt-old benchmark.mlir --pylir-trial-inliner="min-callee-size-reduction=0 max-recursion-depth=200" --mlir-disable-threading' './pylir-opt benchmark.mlir --pylir-trial-inliner="min-callee-size-reduction=0 max-recursion-depth=200" --mlir-disable-threading'
Benchmark 1: ./pylir-opt-old benchmark.mlir --pylir-trial-inliner="min-callee-size-reduction=0 max-recursion-depth=200" --mlir-disable-threading
  Time (mean ± σ):      4.073 s ±  0.037 s    [User: 3.983 s, System: 0.068 s]
  Range (min … max):    4.014 s …  4.148 s    10 runs
Apr 20 2022, 6:53 AM · Restricted Project, Restricted Project
zero9178 updated the summary of D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.
Apr 20 2022, 5:19 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.

Document the conditions for when it is safe to call Operations clone and Regions cloneInto methods from multiple threads.

Apr 20 2022, 5:16 AM · Restricted Project, Restricted Project
zero9178 updated subscribers of D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.

Have you measured the performance of the new clone to ensure parity? Inlining in TF can get kind of heavy...

Apr 20 2022, 5:01 AM · Restricted Project, Restricted Project

Apr 19 2022

zero9178 added inline comments to D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.
Apr 19 2022, 12:05 PM · Restricted Project, Restricted Project
zero9178 updated the diff for D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.

Address review comments regarding documentation

Apr 19 2022, 12:00 PM · Restricted Project, Restricted Project
zero9178 added inline comments to D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.
Apr 19 2022, 8:47 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.

Address review comments

Apr 19 2022, 8:42 AM · Restricted Project, Restricted Project

Apr 18 2022

zero9178 updated the diff for D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.

Address review comments

Apr 18 2022, 1:42 AM · Restricted Project, Restricted Project

Apr 17 2022

zero9178 updated the diff for D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.

Remove redundant includes

Apr 17 2022, 3:25 PM · Restricted Project, Restricted Project
zero9178 requested review of D123917: [mlir] Make `Regions`s `cloneInto` multithread-readable.
Apr 17 2022, 3:23 PM · Restricted Project, Restricted Project
zero9178 requested review of D123913: [mlir] Fix `Region`s `takeBody` method if the region is not empty.
Apr 17 2022, 8:41 AM · Restricted Project, Restricted Project

Apr 11 2022

zero9178 added inline comments to D123412: [mlir][LLVM-IR] Added support for global variable attributes.
Apr 11 2022, 2:55 AM · Restricted Project, Restricted Project

Apr 7 2022

zero9178 committed rG0c789db541c2: [mlir] Add support for operation-produced successor arguments in… (authored by zero9178).
[mlir] Add support for operation-produced successor arguments in…
Apr 7 2022, 11:29 PM · Restricted Project, Restricted Project, Restricted Project
zero9178 closed D123062: [mlir] Add support for operation-produced successor arguments in BranchOpInterface.
Apr 7 2022, 11:28 PM · Restricted Project, Restricted Project, Restricted Project
zero9178 updated the diff for D123062: [mlir] Add support for operation-produced successor arguments in BranchOpInterface.

Define and make use of operator[] in MutableOperandRange

Apr 7 2022, 3:59 AM · Restricted Project, Restricted Project, Restricted Project

Apr 6 2022

zero9178 added inline comments to D123062: [mlir] Add support for operation-produced successor arguments in BranchOpInterface.
Apr 6 2022, 5:13 AM · Restricted Project, Restricted Project, Restricted Project
zero9178 updated the diff for D123062: [mlir] Add support for operation-produced successor arguments in BranchOpInterface.

Address reviewer comments:

  • Add constructor taking just a forwarded operands range
  • Add more documentation to both the SuccessorOperands class and the BranchOpInterface
  • Address comment style issues.
Apr 6 2022, 5:12 AM · Restricted Project, Restricted Project, Restricted Project

Apr 4 2022

zero9178 requested review of D123062: [mlir] Add support for operation-produced successor arguments in BranchOpInterface.
Apr 4 2022, 12:38 PM · Restricted Project, Restricted Project, Restricted Project

Mar 30 2022

zero9178 committed rGe59335e89110: [clang][DR] Add test for DR1227 and mark it as complete (authored by zero9178).
[clang][DR] Add test for DR1227 and mark it as complete
Mar 30 2022, 12:26 AM · Restricted Project, Restricted Project
zero9178 closed D122682: [clang][DR] Add test for DR1227 and mark it as complete.
Mar 30 2022, 12:26 AM · Restricted Project, Restricted Project

Mar 29 2022

zero9178 requested review of D122682: [clang][DR] Add test for DR1227 and mark it as complete.
Mar 29 2022, 1:41 PM · Restricted Project, Restricted Project
zero9178 committed rGc1e614c8eb50: [clang][DR] Test and mark DR1305 as complete (authored by zero9178).
[clang][DR] Test and mark DR1305 as complete
Mar 29 2022, 11:46 AM · Restricted Project, Restricted Project
zero9178 closed D122674: [clang][DR] Test and mark DR1305 as complete.
Mar 29 2022, 11:46 AM · Restricted Project, Restricted Project
zero9178 updated the diff for D122674: [clang][DR] Test and mark DR1305 as complete.

Address reviewers comments: Group test nicely with the other dr namespaces.

Mar 29 2022, 11:43 AM · Restricted Project, Restricted Project
zero9178 requested review of D122674: [clang][DR] Test and mark DR1305 as complete.
Mar 29 2022, 11:20 AM · Restricted Project, Restricted Project
zero9178 committed rG984554f846c4: [clang][DR] Test and mark DR1479 as complete (authored by zero9178).
[clang][DR] Test and mark DR1479 as complete
Mar 29 2022, 12:29 AM · Restricted Project, Restricted Project
zero9178 closed D122620: [clang][DR] Test and mark DR1479 as complete.
Mar 29 2022, 12:28 AM · Restricted Project, Restricted Project

Mar 28 2022

zero9178 requested review of D122620: [clang][DR] Test and mark DR1479 as complete.
Mar 28 2022, 3:14 PM · Restricted Project, Restricted Project
zero9178 added a comment to D121988: [mlir] Fix block merging with the result of a terminator.

Thanks for noticing! I corrected the code-style issues in https://github.com/llvm/llvm-project/commit/a7865228b30dc019c0d13d0c81247d90fcad325b

Mar 28 2022, 7:56 AM · Restricted Project, Restricted Project
zero9178 committed rGa7865228b30d: [mlir][NFC] Fix codestyle issues introduced in D121988 (authored by zero9178).
[mlir][NFC] Fix codestyle issues introduced in D121988
Mar 28 2022, 7:55 AM · Restricted Project, Restricted Project

Mar 21 2022

zero9178 committed rGe13d23bc6ccd: [mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand` (authored by zero9178).
[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`
Mar 21 2022, 1:43 PM · Restricted Project, Restricted Project
zero9178 closed D122142: [mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`.
Mar 21 2022, 1:42 PM · Restricted Project, Restricted Project, Restricted Project
zero9178 updated the diff for D122142: [mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`.

clang-format correctly this time & trigger build bot

Mar 21 2022, 1:24 PM · Restricted Project, Restricted Project, Restricted Project
zero9178 updated the diff for D122142: [mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`.

Rename to "UnresolvedOperand" instead of "OperandReferences" & clang-format

Mar 21 2022, 11:58 AM · Restricted Project, Restricted Project, Restricted Project
zero9178 added a comment to D122142: [mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`.

Thank you for tackling this! I agree that "OperandType" isn't the right thing, but I don't think "OperandReference" is either. The key thing about this is that it models an occurrence of an SSA value in an operand position, but without having a type applied to it. "Operand" and "Reference" are somewhat redundant.

What do you think about a name like "UnboundOperand" or "OperandWithoutAType" (joking but may you have a better idea) or OperandSyntax or LexicalOperand?

Mar 21 2022, 9:29 AM · Restricted Project, Restricted Project, Restricted Project
zero9178 updated the diff for D122142: [mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`.

Rename occurrences in variable names as well as comments as well (Only found a few in Parser.cpp)

Mar 21 2022, 8:15 AM · Restricted Project, Restricted Project, Restricted Project
zero9178 updated the summary of D122142: [mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`.
Mar 21 2022, 8:07 AM · Restricted Project, Restricted Project, Restricted Project
zero9178 requested review of D122142: [mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`.
Mar 21 2022, 8:06 AM · Restricted Project, Restricted Project, Restricted Project
zero9178 added a comment to D121571: [TableGen] X86 mnemonic tables backend.

An LLVM build of mine that has UBsan enabled has started failing since this commit. The error itself is:

[5/1719] Building X86GenMnemonicTables.inc...
FAILED: lib/Target/X86/X86GenMnemonicTables.inc
cd /mnt/c/LLVM/llvm-project/llvm/build-wsld && /mnt/c/LLVM/llvm-project/llvm/build-wsld/bin/llvm-tblgen -gen-x86-mnemonic-tables -asmwriternum=1 -I /mnt/c/LLVM/llvm-project/llvm/lib/Target/X86 -I/mnt/c/LLVM/llvm-project/llvm/build-wsld/include -I/mnt/c/LLVM/llvm-project/llvm/include -I /mnt/c/LLVM/llvm-project/llvm/lib/Target /mnt/c/LLVM/llvm-project/llvm/lib/Target/X86/X86.td --write-if-changed -o lib/Target/X86/X86GenMnemonicTables.inc -d lib/Target/X86/X86GenMnemonicTables.inc.d
../utils/TableGen/X86MnemonicTables.cpp:52:29: runtime error: load of value 96, which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../utils/TableGen/X86MnemonicTables.cpp:52:29 in
Mar 21 2022, 7:10 AM · Restricted Project, Restricted Project
zero9178 committed rGc14ba3c4be09: [mlir] Fix block merging with the result of a terminator (authored by zero9178).
[mlir] Fix block merging with the result of a terminator
Mar 21 2022, 5:27 AM · Restricted Project
zero9178 closed D121988: [mlir] Fix block merging with the result of a terminator.
Mar 21 2022, 5:26 AM · Restricted Project, Restricted Project
zero9178 added a reviewer for D121988: [mlir] Fix block merging with the result of a terminator: ftynse.
Mar 21 2022, 2:10 AM · Restricted Project, Restricted Project

Mar 18 2022

zero9178 requested review of D121988: [mlir] Fix block merging with the result of a terminator.
Mar 18 2022, 3:30 AM · Restricted Project, Restricted Project

Feb 23 2022

zero9178 added a comment to D120243: allow for contention free exception unwinding.

Please stop wasting time on fixing C++ EH. Start to work on herbceptions. I use llvm mainly for compiling wasm programs and a lot of other environments which don't have the EH support. Adding "fix" to libunwind is not going to address any real issue with EH while adding an inifinite amount of pain to support new platforms (like wasm for example).

Time to deprecate C++ EH tbh. Even LLVM itself does not use EH.

Feb 23 2022, 6:00 AM · Restricted Project, Restricted Project

Feb 15 2022

zero9178 added inline comments to D119903: [PDLL] Add proper expansive documentation for PDLL.
Feb 15 2022, 4:34 PM · Restricted Project, Restricted Project
zero9178 added inline comments to D108416: [llvm-libgcc] initial commit.
Feb 15 2022, 8:33 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project
zero9178 committed rG78c27a3cee42: [X86][Win64] Avoid statepoints in trailing call position (authored by zero9178).
[X86][Win64] Avoid statepoints in trailing call position
Feb 15 2022, 3:17 AM
zero9178 committed rGdb8ae2fef159: [llvm][doc] Update comments and documentation of custom stackmap formats in GC (authored by zero9178).
[llvm][doc] Update comments and documentation of custom stackmap formats in GC
Feb 15 2022, 3:17 AM
zero9178 closed D119644: [X86][Win64] Avoid statepoints in trailing call position.
Feb 15 2022, 3:17 AM · Restricted Project
zero9178 closed D119660: [llvm][doc] Update comments and documentation of custom stackmap formats in GC.
Feb 15 2022, 3:17 AM · Restricted Project

Feb 14 2022

zero9178 updated the diff for D119644: [X86][Win64] Avoid statepoints in trailing call position.

Makes use of the isCall property of a machine instruction instead of specializing for statepoint in particular.
That way the code fixes the issue for any pseudo instruction that lowers to a call.

Feb 14 2022, 2:14 PM · Restricted Project
zero9178 added inline comments to D119644: [X86][Win64] Avoid statepoints in trailing call position.
Feb 14 2022, 2:13 PM · Restricted Project