Of course there was another merge conflict in the release notes. Mental note to self: Put release note changes in separate commit.
Fixed the last spelling issues in the documentation. If the automated checks pass, this is ready for takeoff from my side. Thanks for your reviews!
Fix spelling issues in doc
The code changes look simple enough, LGTM.
I think it would make more sense to do this during instruction selection, rather than in a separate pass, but for now it seems easiest to just copy what selectiondag does and run the pass.
Rename to getExtendedAddReductionCost and adjust some hasOneUse early exits.
I was referred to this patch from https://reviews.llvm.org/D86743. I pulled this patch under review, brought it up to date and pushed to github at https://github.com/vabridgers/llvm-project-dev.git, branch: vla-fam-fixes. Everything seems ok on this branch (LITs pass, reproducers from https://bugs.llvm.org/show_bug.cgi?id=47272 and https://bugs.llvm.org/show_bug.cgi?id=28450 no longer crash). I can continue and push a change to Phabricator for review, or @Charusso and/or @balazske could finish this? I didn't want to just push an update without asking first :/ Cheers!
I think "Week number" is too ambiguous to be a guide. If January starts on the last day of the week, does that still count as week#1? What day does the week start on, anyway--much of the world starts the week on Sunday, much of the world starts the week on Monday.
"Fourth Tuesday in January/July" is unambiguous and makes everything easier to plan. Using "Start + N weeks" for the rest of the target dates is fine.
Exposing simpler API
Summary of changes:
The existing fusion tests seem a little bit weak—the machine scheduler with the base Cortex-A57 machine models that most of those use seemed to pass the address and literal fusion on its own (by coincidence?) without the explicit features requested. I was unable to make that test case stronger to see the A57 machine model not exploiting those fusion pairs when the feature was disabled. Is that worth worrying about?
Adapted to comments
- Address review comments.
Adapted to comments.
These LGTM. This patch should presumably be marked dependent on D94637.
I don't think any of the other patches in the stack update the comment at the top of RISCVInstrInfoB.td to say "version 0.92" rather than "version 0.93", and this is probably a reasonable patch to do it in.
Change to use separate output file to aid debugging.
@kito-cheng could you please confirm that this patch handles sub-extensions in the same way GCC does. i.e. -march=rv32izbb0p92 defines __riscv_zbb but NOT __riscv_b? That seems logical to me, as otherwise it would be cumbersome to check if the whole extension is supported rather than just a subset, but I just wanted to confirm.
Thanks for feedback. I agree that providing diagnostics for unsupported core features is enough for now (I guess I'll try to come up with something for OpenCL C 3.0 features to set them unconditionally for 2.0, or at least these macros can be defined in header only). So I removed setting of core features (and also addressed all cosmetic concerns).
Switch to primary context.
Add more tests
LGTM with a nit, please wait for others.
Reupload diff. Previous diff somehow was missing one of the changes.
missing check-prefix. Not sure how I didn't spot the latter...
Empty lines removed.
Fix reference to stale object and missing check-prefix. Not sure how I didn't spot the latter...
I can see that InstructionView has been moved outside of View.h into its own file, but I cannot see that new file anywhere in this diff.
There is still an issue if the SGPR used to hold the input llvm.amdgcn.init.exec.from.input is spilt; however, this is not a new issue.
From my testing llvm.amdgcn.init.exec.from.input actually only worked in the entry block previous to this change, so we could tighten its description even further.
I am not sure what the problem is. May be we can fix it later. But I don't want to restrict it can only be used in the entry block for now unless we later prove that is really hard to make it correct. We may possibly use it for the second part of the merged shader.
This change broke one of our downstream tests and the issue can be reproduced with the following test:
# REQUIRES: x86
Now with assert.
Not sure why we even run the DSYM variant if the test disables building DSYM. I just made this a no-debug-info-test in 060b51e0524aed6b6cc452baa8eb6d663a580eee which gets it running again on the bots for now.
LGTM, but should we document these "extra" things we're doing on top of the published spec? I'm not sure where, but it might help someone reading the spec as written.
- Added more cost model test cases and optimised existing ones.
- Renamed vectorisation tests to something more useful. :) I also reduced the number of CHECK lines as it looked too messy and fragile.
This is breaking the functionalities/archives/TestBSDArchives.py test on macOS. It seems the MAKE_DSYM flag somehow looses its effect when the dsym version of the test is running (and then we fail generating a dsym without input files): http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/27711/testReport/junit/lldb-api/functionalities_archives/TestBSDArchives_py/
Replace regression test with David's smaller test
- Remove duplicate tests
- Some code cleanups as per review comments
My hope is to get the 0.93 move into LLVM 12. Zbb is marked frozen in the 0.93 spec and does not include these. So I'd at least like them out of Zbb. Would it be better to just remove them until they have a home?