- User Since
- Jan 15 2015, 3:04 AM (384 w, 2 d)
Jan 20 2022
Dec 23 2021
Suggest clarifying the commit message to something like:
Aug 26 2021
Jul 30 2021
Jul 27 2021
Jun 24 2021
Jun 21 2021
I'll leave the review open for a couple of days in case anyone sees a problem with the additional .addReg(AArch64::LR), otherwise I'll commit.
The following commit added a register in the definition of the PAC instructions:
Jun 16 2021
@efriedma thank you for the review. Commit updated without the special outlining handling.
Jun 15 2021
Jun 10 2021
Jun 3 2021
Jun 1 2021
May 24 2021
All comments addressed (thank you @danielkiss). Does it look reasonable now?
May 13 2021
Updated PAC handling in the outliner. Now all outlined functions should use v8.3a instructions where possible.
May 11 2021
Added handling of outlining for PACI* similarly to PACI*SP etc, and RegState info to SP.
May 5 2021
Apr 14 2021
Apr 13 2021
Apr 9 2021
Sure thing, thank you for the review. @MaskRay please let me know if you want to further discuss the changes to the patchable-function-entry test, otherwise I will commit this sometime next week.
Apr 7 2021
Mar 30 2021
For patchable functions are there any other cases where we wouldn't generate a BTI at the start of the function? If there is we may be alter the test so that it is still checking that the nop is still inserted. If there is no way to avoid a BTI then we may have to alter the expected result and the comment.
I've dug up https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424 and https://reviews.llvm.org/D72215 for context.
Reintroduced the removed fpatchable-function-entry test, but modified so that it expects a landing pad at the beginning of the function.
Mar 26 2021
@MaskRay sorry to pull you into this review - feel free to ignore if you're not interested.
Mar 12 2021
Nov 10 2020
Nov 9 2020
Diogo, Victor, thanks for the review. I am going to attribute the failure in the HWAddressSanitizer to something else, since it looks x86-related and this patch doesn't touch anything near x86 support.
Nov 2 2020
Jun 5 2020
This is the same logic that we applied to PAC mnemonics in https://reviews.llvm.org/D78372. I'll approve but I would recommend to wait for a few days in case anyone else has something to say.
Apr 24 2020
Apr 21 2020
Another rebase to pass C.I. - looks like it was broken outside this commit
Rebase to trigger C.I.
Apr 17 2020
Mar 5 2020
Jan 22 2020
Jan 16 2020
Jan 13 2020
Updated tests and rebase conflict with new "isAuthenticated" predicate
Jan 2 2020
Dec 18 2019
Sep 30 2019
Sep 27 2019
Reworded all the FP & SIMD constraints
Discussing with @chill on a chat, he was happier with the following wording:
Sep 26 2019
Sep 23 2019
Sep 18 2019
Hi, CMSE upstreaming is indeed one of our priorities. So yes, we are very interested in your feedback. And no, CMSE upstreaming is not abandoned, just going a bit slow ATM :( but any help reviewing is much appreciated! :)
Aug 9 2019
Aug 8 2019
Aug 5 2019
Aug 2 2019
Jul 25 2019
Jul 19 2019
Oooops sorry, not sure how I missed that. I've added SSBS to all the CPUs now.
Jul 18 2019
Add Cortex-A65 and a few features that were missed in the first patch. I think all the features should be in now.
Jul 11 2019
These are trace extensions that will be used by a niche group of developers. They add no instructions (only system registers) and they will not be generated by the compiler. Adding them by default does not have any side-effect, i.e. everyone will still see the same behavior in their code unless they start using these registers on purpose.
Jul 9 2019
Jan 25 2019
Same idea as https://reviews.llvm.org/D54961 but for two other command line options. Approved!
Dec 3 2018
Rebased onto master after a recent refactoring of the AArch64 target parser.
Nov 27 2018
Thank you for the review, Sam :)
Nov 19 2018
The Armv8.5-A specification is available here: https://developer.arm.com/products/architecture/cpu-architecture/a-profile/exploration-tools
Nov 16 2018
Mar 1 2018
Buildbot failing here: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/2998
Feb 28 2018
Feb 23 2018
If nobody does it before, I'll give it a try early next week.
Feb 15 2018
I'll commit this fix now to prevent other buildbots to fail.
Related fix for a silly errata in one of the tests that is breaking some Windows buildbots:
Committed now. @rengolin many thanks for the review!
What about 32-bit integers?
Feb 13 2018
There is still the possibility that someone tries to use 't' for a vector of two doubles. Only single-precision is allowed in vector operations for 32-bit architectures, so doing something like this would be illegal:
Added tests for int vectors. Allowing integers to go to FP/vector registers is
useful because FP/int conversion instructions (i.e. VCVT) need that.
Feb 12 2018
AFAICS, the current approach just checks the size of the type, not the size of the sub-type. f64 or even integer types could still leak in, no?
To prove they're not, we need tests making sure they break if you try.
Feb 7 2018
Feb 6 2018
Feb 1 2018
Sorry, I missed the sanitizer failure in yesterday's buildbot message and thought it wasn't related to this patch. I will leave some time for @thebolt to fix it, otherwise maybe I can take a look.
Jan 31 2018
Committed now. Thanks for the patch @thebolt!
I'll do it.
Jan 29 2018
LGTM now. In other circumstances, I would wait for someone more experienced than me, but this is a small peephole optimization. I've also tested the patch and it works correctly, so I think it has very little risk.
Jan 26 2018
The logic & testing LGTM. Just a couple of coding standard nits.