- User Since
- Apr 29 2022, 12:34 AM (74 w, 1 d)
Thu, Sep 28
Aug 1 2023
Jul 25 2023
Jul 11 2023
May 19 2023
May 16 2023
Mar 7 2023
Mar 6 2023
Submitted https://github.com/llvm/llvm-project/commit/f2cdccc034d0696f186f55d6826dd6ac40e4d3d5 for now that restores the preloading behavior, and fixes the test that was failing in our internal configuration. If we really need to support running commands that expect to be given an EOF input to work, we can work on our internal lit runner to support that, but I would prefer to have a heads-up for that before.
Yes, "registered" is what I meant.
Right, any convenient ways to just get a list of loaded dialects from a script. mlir-opt --show-dialects --version doesn't work (I guess version is processed before we get to --show-dialects), and echo "" | mlir-opt --show-dialects is a weird thing to have.
Ah, the --show-dialects option is no longer a stand-alone thing, but an additional printout, where you could also do other things. So I guess in my example it's still waiting for some IR as input.
This seems to cause mlir-opt to hang when passed the --show-dialects option. Ran it through bazel:
Feb 3 2023
Jan 31 2023
Jan 17 2023
From my experience integrating MLIR into Google's internal repository, breakages from changes like these seem to be very frequent (e.g., the two already mentioned above), so I don't see why this change should be blocked while others get a pass. If we want to be more careful about API breakages, then we should first formalize this somehow and apply the same rules to everyone.
I never considered the printed version of MLIR stable, and I'm not sure that its stability should be the goal that prevents improvements to the printing format.
Regarding churn, we should not forget that not improving the printed format also causes churn every time someone is reading or modifying it.
I think that redundancy in IR causes more issues than it solves, so I would prefer landing this change.
Jan 12 2023
Jan 11 2023
Also lower math.tan for ROCDL
Jan 10 2023
Nov 10 2022
It's even less OK to fail altogether (which is what is happening without this patch). And we're not talking about the new semantics for FMINIMUM/FMAXIMUM, but for the new semantics of FMINNUM/FMAXNUM (the +/-0 handling changed).
I think this is the best we can do short of adding a new op. We only do the expansion for the NVPTX backed, and don't support it otherwise. In the NVPTX backed, the intermediate code still ends up being semantically incorrect for +/-0.0, but since FMINNUM/FMAXNUM lower to PTX min/max, which do implement the 2018 semantics of those ops, the final PTX ends up being correct.
Limit expansion only to NVPTX backend
Nov 9 2022
@nikic 0 handling should be fixed now
Change lowering to minnum/maxnum + NaN check
Nov 8 2022
Oct 10 2022
Aug 22 2022
May 31 2022
We can achieve what we need by adding LoopInvariantCodeMotionPass. Abandoning this.
In essence, the issue is that tiling, mapping to gpu and the transformation to gpu dialect have to run after each other without being disturbed by other passes.
May 30 2022
Worked like a charm.
Prevent merging loops with attrs instead
Sure, I can change to addWithLabel instead.
May 24 2022
May 3 2022
Make combine a regular function, use CHECK-DAG, formatting