User Details
- User Since
- Jul 30 2018, 4:54 AM (234 w, 6 d)
Jan 21 2022
LGTM
Dec 21 2021
Dec 14 2021
Dec 9 2021
Nov 19 2021
Address comments
Nov 18 2021
Oct 28 2021
Oct 26 2021
I'm fine with allowing vectors, but shouldn't we then also allow vectors for the G_*BFX? What was the reason for disallowing them there?
Oct 25 2021
Thanks for the quick review @foad!
Add comment about range of operands
Oct 22 2021
Rebase & ping
Oct 10 2021
Sep 16 2021
Sep 9 2021
Only apply combine if the mask does not exceed in-memory size
Sep 8 2021
Address review comments
Sep 7 2021
Sep 3 2021
Remove constexpr
Sep 2 2021
Aug 25 2021
Aug 24 2021
Aug 10 2021
Use available ShiftAmtTy
Aug 9 2021
Rebase + test updates
Aug 2 2021
Jul 28 2021
ping @arsenm
Jul 9 2021
Is anyone already looking into supporting narrowing the result type below the memory size?
Jun 16 2021
Jun 14 2021
Jun 9 2021
Remove the check for noload, adapt existing tests
https://reviews.llvm.org/D45264 specifically introduced the check for sec->noload, stating that this conforms to GNU ld 2.29
Jun 8 2021
Thanks for your comments! I've applied the suggested formatting changes.
Test formatting
Jun 7 2021
May 25 2021
Mar 1 2021
Is there a plan to eventually get rid of the EVTs in call lowering and directly work with the LLVM IR Type?
Our downstream target needs special handling for pointer arguments, but unfortunately ComputeValueVTs loses the information about pointerness.
We solved this by directly operating on the LLVM IR type, although we do not handle vectors yet, which makes this a bit simpler
Jan 15 2021
Adapt to new API of getConstantVRegValWithLookThrough, rebase
Oct 16 2020
Oct 15 2020
Yes, I'll commit it tomorrow, thanks for the review @akyrtzi!
Oct 12 2020
Address review comments
Oct 9 2020
Aug 20 2020
Aug 19 2020
Aug 18 2020
Aug 13 2020
Aug 4 2020
The promotion gets inserted in the libcall lowering [...]
Either you can create a bug in Bugzilla (https://bugs.llvm.org/), asking for this revision to be merged to the release branch and mark it as a release blocker of the 11.0.0 release, or you can contact the release manager directly (hans@chromium.org).
Aug 3 2020
LGTM, might be worth to include this also for the 11.x release.
Jul 23 2020
Rebase
Jul 14 2020
Jul 8 2020
A similar issue (for tied input operands) is handled in https://reviews.llvm.org/D83384
The function introduced there should be extended to handle the vector case.
we noticed that this extension is also missing for the non-tied register input operands. I added the opposite logic, i.e. truncating of output operands, but forgot about extending the inputs.
Would you mind adding that handling in this patch too, as it is basically the same?
If you feel like it should be in a separate commit, I can also provide a patch for it. Thanks!
Jun 10 2020
I brought this to the mailing list (http://lists.llvm.org/pipermail/llvm-dev/2020-March/140032.html) but didn't get an answer there.
Brining this up again
Yes, abandoning this in favor of https://reviews.llvm.org/D78316
May 27 2020
May 23 2020
May 22 2020
Hi @leonardchan, I'll take a look at the failure, thanks for the reproducer!
May 15 2020
Re-landed in 5425cdc3adf9998aeaf587d93417bd2f4f1373c9
The new check also triggered for memory clobbers, which we already handle.
I've moved the check further down, where we already check that it is an input operand.
Re-opening for investigation
May 14 2020
Add test extracted from pr68328.c
I did not handle direct memory operands that need to be "indirectified" in this patch.
https://reviews.llvm.org/D79955 adds an early return for now so we don't run into the assertion while working on supporting that feature.
I'll have a look into it now. Thanks for letting me know!