User Details
- User Since
- May 24 2017, 3:29 AM (191 w, 1 d)
Fri, Jan 8
Wed, Jan 6
LGTM
Tue, Jan 5
LGTM.
Tue, Dec 29
Dec 21 2020
Nov 30 2020
In the Arm Architecture Reference Manual Supplement - Armv8, for Armv8-R AArch64 architecture profile
"A1.4 Architecture extensions" lists among others
Nov 13 2020
LGTM, thanks.
Nov 9 2020
Thanks!
Nov 7 2020
Nov 6 2020
Nov 5 2020
Cheers!
Cheers!
Nov 4 2020
That should be the minimum number of instructions now, one less and the outlining does not pass the cost threshold.
Ping.
Nov 3 2020
Nov 2 2020
Ping.
Ping.
Oct 28 2020
Ping.
Ping.
Oct 23 2020
Oct 22 2020
Oct 17 2020
Oct 16 2020
Oct 15 2020
Oct 10 2020
Oct 2 2020
Sep 28 2020
Sep 25 2020
In D85649 I changed the module flags to be always present and have a zero/non-zero value. That's needed during LTO, if a flag is present in one module and absent in another,
no error is reported and the existing flags is used in the merged module, affecting the codegen for the module that did not initially have the flag.
Sep 24 2020
Rebased.
LTO related fixes - user Error combining behaviour, always emit the attributes with values 0 or 1
so they are present and their values can be checked for being the same during.
Sep 21 2020
Some tests started failing: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-ubuntu/builds/9071
Sep 18 2020
It looks like the only value that makes sense is Error - any other policy (existing or not) would potentially lead to meaningfully different code generated with or without LTO.
Sep 17 2020
Thank you for your comments. I'd like to have the same behaviour with or without LTO, which is apparently not the case with this patch.
Sep 16 2020
Ping.
Ping
Sep 8 2020
Ping,
Sep 7 2020
LGTM.
Ping.
Sep 2 2020
LGTM. It'd be nice if we could get someone non-Arm to have a look too. though.
LGTM, as soon as D85649 is accepted (so they stay in sync).
Emit function-level LLVM IR attributes only when there's a GCC-style function attribute and be explicit with enabling/disabling.
Fixed an error where "none" in deferred to module attributes, instead of overriding them.
No, not yet.
Sep 1 2020
In addition to the disabling of BTI in D81251, there's an issue that we explicitly disable BTI via branch-protection=none, the attribute would just be missing and we'll pick up the module attributes, which is not what we want.
Aug 27 2020
Ping?
Aug 25 2020
Aug 24 2020
It does, we're using different module attributes.
Aug 21 2020
In D85649 I suggested a different version of module flags, which is a bit nicer to use, e.g. one can say just
getModuleFlag("sign-return-address-with-bkey") != nullptr
instead of a) checking for the flag presence, b) getting its value and c) comparing it to a set of strings, which is
way too verbose.
Aug 20 2020
Thanks!
Aug 19 2020
Ping?
Aug 18 2020
Ping?
Aug 17 2020
Aug 12 2020
Is there a test for no module attributes + function level attribute enabling pac/bti that tests that just that function gets the proper handling?
Aug 11 2020
Well, it wasn't completely broken, just a little bit :D
Aug 10 2020
Updated the patch to unconditionally include PAC stripping instructions, NOP-space ones to non-NON-space ones, depending on
whether v8.3-a (soo to be '+pa') feature.