- User Since
- Apr 30 2013, 5:34 PM (404 w, 23 h)
LG with fixing the wording as Alex suggests (and clang-tidy flags)
Oh I see what you mean, we'd replace the current llvm::StringSet<llvm::BumpPtrAllocator &> identifiers; in the MLIRContext with something like llvm::StringMap<Dialect*, llvm::BumpPtrAllocator &> identifiers;?
(probably a bit more complex, but that's the rough direction?)
This patch is fine, but I'd still be interested to understand if this could be made to show up during check-mlir with one of the Cmake configuration that can run on Windows?
Some Locations may be using Identifier like in FileLineColLocationStorage.
An OperationName would get larger as well I think, which would make Operation larger by one pointer (it'd accelerate Operation::getDialect() for unregistered operations, but I don't think we need to optimize this)
Mon, Jan 25
Thanks for the cleanup!
You can search in mlir/test for test that invoke mlir-translate with -mlir-to-llvmir
Thanks! It is exciting to start seeing the FIR change coming upstream!
Sun, Jan 24
Sat, Jan 23
Fri, Jan 22
Thu, Jan 21
(fix the description before pushing)
LGTM with a minor tweak on FileReproducerStream
Landing now, feel free to add more comments as needed!
Wed, Jan 20
Add a body_builder callback
Can you add a lit test for this?
Do you need me to land this for you?
Minor update to add_entry_block + test fix
Address comment, add more helpers/properties on FuncOp, extend the test
Since the split of the standard dialect has begun, can you create a math dialect and move this kind of operations there?
Tue, Jan 19
We don't need to test completeness: i.e. no need to test every feature from ODS, just basic plumbing here (import and create / round-trip one or two ops), that's why I mentioned "smoke test".
I guess it'll be more useful with the registration aspect sorted out.
I think it'd be preferable to write basic smoke tests for the bindings when adding these.
Mon, Jan 18
We generally use code review for everything except build unbreaks, reverts and minor syntactic changes such as typos.
Sat, Jan 16
Thu, Jan 14
Phab linked the commit as "added a commit" to this revision, I'm not sure why it didn't close it...
Wed, Jan 13
LGTM in general.
Tue, Jan 12
If the runners depends on libSupport and we link them statically into the runtime wrapper that are dynamically loaded, aren't we having two copies of libSupport? One in the statically linked runner executable and one in the dynamically loaded shared objects?
Mon, Jan 11
Thanks for adding the description: I still don't quite get how making these static is preventing an ODR issues?
Sorry I had to revert in 110775809ad1 as it broke the gcc-5 build (which has been broken for hours by another change that just got reverted, so I didn't want to lose more coverage right now and need to get it back green ASAP).
Can you add a description of the motivation to the commit message?
Sat, Jan 9
Fri, Jan 8
Thu, Jan 7
Still LGTM! Do you have commit access or do you need someone to land it for you?
To bisect a build failure, is is more reliable to just build the target that is failing, i.e.: ninja projects/debuginfo-tests/CMakeFiles/check-gdb-mlir-support.dir/llvm-prettyprinters/gdb/mlir-support.cpp.o