- User Since
- May 24 2017, 3:29 AM (173 w, 2 d)
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.
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.
Wed, Sep 16
Tue, Sep 8
Mon, Sep 7
Wed, Sep 2
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.
Tue, Sep 1
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.
Thu, Aug 27
Tue, Aug 25
Mon, Aug 24
It does, we're using different module attributes.
Fri, Aug 21
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.
Thu, Aug 20
Aug 19 2020
Aug 18 2020
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.
I would prefer to avoid the situation where the markings of two otherwise identical files were different,
depending on how the files were produced, no matter if it was a common or a special case.
I don't share this assumption. I find it just as valid to control the PAC/BTI with things like:
#ifdef ENABLE_BTI #define BTI_FUNC __attribute__((target("branch-protection=bti"))) #else #define BTI_FUNC
Aug 7 2020
Aug 5 2020
My original idea was to pass options to LLVM. I'll come up with a patch in a day or two (if it works) and then we'll see.
I'm in favour of changing these patches to unconditionally emit XPACLRI (i.e. HINT #whatever).
Aug 4 2020
This approach looks way too hackish to me with multiple opposing attributes ("sign-return-address" vs. "ignore-sign-return-address")
and some convoluted logic to resolve the contradiction.
Is this patch needed anymore?
Jul 31 2020
Let's postpone this just for a little bit, to settle on an approach to depth > 0.
Jul 30 2020
Jul 29 2020
Jul 24 2020
Jul 23 2020
Jul 22 2020
Err, they do mention the operand, but only as an input one, it should be input/output.
Jul 21 2020
I'm afraid the patch does not work yet. For example, when the following program
I don't think this behaviour is correct with regard to the specification (AAELF64 2020Q2):
Jul 2 2020
Jul 1 2020
Needs a regression test. This patch and the dependent patch clash, better with a single patch.
Jun 23 2020
Jun 22 2020
Jun 19 2020
Jun 18 2020
Yeah, I'd prefer that, but then I'm hesitant to change APIs.
Jun 17 2020
Jun 16 2020
Pretty straightforward, LGTM. I'd suggest rewording the title (presumably commit message summary) into something like "Do not coerce bfloat arguments and returns to integers", as we're obviously still lowering C and C++ to LLVM LR.§§
Jun 15 2020
Jun 12 2020
Updated to take into account liveness of registers. Whenever we blanket push registers, the live ones are ordinary operands,
the dead ones are Undef operands.
Jun 10 2020
May 15 2020
LGTM, thank you.
May 14 2020
I'm sorry, I don't understand the issue. Certainly it's the compiler (driver) responsibility to setup include paths according to the selected target.
How do you trigger a problem?
May 7 2020
The last version of the patch broke compilation with expensive checks - the machine verifier
reported a score of lifetime errors.
In this update, we are more precise with the RegState flags when creating instructions
to save/restore/clear registers around non-secure calls and before return to non-secure state.