Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
LGTM
| llvm/test/Analysis/ValueTracking/knownbits-bmi-pattern.ll | ||
|---|---|---|
| 269 | FWIW, I would remove all but one of these vector assume tests. They don't really add anything in a world where we just don't support vector assumes. (If we were to add support for them, that would get separate test coverage, and I doubt the canonical pattern we'd require for them would look like what you're doing here -- we'd probably want an assume over an and reduction.) | |
Remove some unneeded vec tests, add case where checking X/-X is necessary
| llvm/test/Analysis/ValueTracking/knownbits-bmi-pattern.ll | ||
|---|---|---|
| 269 |
Removed all but 2, one for blsi and one for blsmsk (one for add_eval and one for cmp_eq). Unrelated but I see you have a page tracking llvm build times. Do you know what the fastest build flags are for building clang itself (for development/rebuilding, don't care about executable perf, just want it to build v fast)? | |
| llvm/test/Analysis/ValueTracking/knownbits-bmi-pattern.ll | ||
|---|---|---|
| 269 |
Note that these are build times of other software when compiled with clang, not time to build clang :) I did actually start to track time to build clang recently, resulting in this fun graph (on a 6 core server): https://llvm-compile-time-tracker.com/graphs.php?stat=wall-time&startDate=2023-01-22&bench=clang Thanks to ccache, build times tend to jump between 40 seconds and 25 minutes.
Not really. It would probably be an unoptimized build without debug info, but if you also want to run tests, it will be slower overall. I'm personally using release+asserts builds with lld and ccache. Only strong recommendation I have is to not use debug builds outside exceptional circumstances. They are miserable on so many levels, and you're almost always better served using -debug logging instead. | |
| llvm/test/Analysis/ValueTracking/knownbits-bmi-pattern.ll | ||
|---|---|---|
| 269 |
I see, I do basically the same but -O1 instead of release to make things a bit faster. It might be useful to add a flag --build-fast that has some passes (like elim alloca that AFAICT make things faster) but is only trying to get the build done as fast a possible rather than optimizing. Might save a handful of dev time. Thanks for the info :) | |
FWIW, I would remove all but one of these vector assume tests. They don't really add anything in a world where we just don't support vector assumes. (If we were to add support for them, that would get separate test coverage, and I doubt the canonical pattern we'd require for them would look like what you're doing here -- we'd probably want an assume over an and reduction.)