Hey,
I wanted to check if anyone uses (or has successfully used within last 9 months) mlir-reduce.
Context: some discussion threads about it not working and wanting to check the utility before further discussion.
– Jacques
Hey,
I wanted to check if anyone uses (or has successfully used within last 9 months) mlir-reduce.
Context: some discussion threads about it not working and wanting to check the utility before further discussion.
– Jacques
Last time I tried mlir-reduce, I had no success at all. People pointed me to iree-reduce, which is supposed to be closer in design to llvm-reduce; but I never actually tried it.
Coincidentally, to begin improving mlir-reduce and make it actually useful, some ideas may be taken from llvm-reduce: Improvements to llvm-reduce
I’ve never understood how such a tool could be made generic to “mlir” abstractly and considered this an experiment from the very early days.
If it’s not usable and not maintained, I think we should delete it.
Oh that’s rather “easy”, even tools like GitHub - googleprojectzero/halfempty: A fast, parallel test case minimization tool. could serve the role without a priori knowledge, the directedness and invalid inputs would just be rather significant. It’s where extensions become useful/needed.
I think that’s part.of my question: improve or restart. The functionality is good, but it’s unclear if it’s a useful base.
I’d vote for restart.
My experience with that kind of tool though is that you don’t want to fight through a maze of abstractions to add heuristics.
Maybe if more of a library for making such a thing vs a tool per se (or just a tool with an example instantiation).
It’s not clear to me what you’re basis this comment on right now: I would think that this kind of proposal would follow a careful analysis of the design of mlir-reduce, and the code that’s there, comparing where we want to be with where we are today, and what’s the best path forward.
We know of to make things pluggable and extensible… Not everyone buys into it, lot of MLIR-skeptics made the same kind of comments multiple times about the whole concept of MLIR itself over the years!
This is how we build almost everything in MLIR: mlir-opt, mlir-translate, etc. are all “tool instantiations” baked by extensible libraries!
I don’t see mlir-reduce
any differently here.
I’m not going to engage more on this thread. But my basis is that when:
The pragmatic thing to do is to delete and start from a fresh state. That’s just good software engineering hygiene.
Perhaps, but those who fail to learn from the past repeat it. In the past, at least, this seemed to be a somewhat useful tool
within some scope, but I haven’t used it recently. I’d rather have something that is useful within some bounds than not.
Which is exactly the question Is it still useful? Does it even work still? There are multiple different variants of this tool in different repos, all decided to roll their own rather than use it as base. Which is why I’m trying to see if it has/hear from it’s users (I tried using it a few months ago and it didn’t work, but that’s just two data points).
Sharing my mlir-reduce experience here, since I think people on this thread might be interested: