Would it still make sense to have this patch after D68683 lands? At first sight, it seems this patch might no longer make sense then?

LGTM, thanks!

Thanks for persevering Sam.

Given this seems to add a new IR instruction, shouldn't there also be good quality documentation for this new instruction in docs/LangRef.rst?

In D67485#1676748, @t.p.northover wrote:

Enabling the corresponding subtarget feature on cyclone doesn't seem safe to me. If we ever implement -mtune, then a command line like clang -march=armv8a -mtune=cyclone should mean “generated correct code for the v8.0 architecture, but optimize for cyclone". Adding this feature to cyclone as is would probably result in the above command line producing code that isn’t architecturally correct for v8.0.

I don't think Clang really does anything with -mtune yet. The most it could do based on the way CPUs are implemented in LLVM now would be something like applying the scheduling model. Almost all of the features in the list are going to break older CPUs.

Thanks Sam, I think this is starting to look good!
I just had a few more nit-picky comments.

LGTM

I'm afraid I'm not up to speed on statepoints, but I thought I'd give some feedback nonetheless on the code as is.
I hope it's useful.

I think you also need to call out the new SingleSource/Regression/C/gcc-c-torture directory in the top-level LICENSE.TXT file as a directory containing non-LLVM licensed material (see bottom of the top-level LICENSE.TXT file).

I've just added a few fly-by nits; I'm afraid I didn't do an in-depth review.

Thank you very much Ziang for sharing this work!
I'd love to more easily benchmark on Android devices - and this seems to be a good step in the right direction.

In D61597#1577730, @lenary wrote:

In D61597#1577701, @kristof.beyls wrote:

I wonder what the other issues are you're seeing after applying this patch?
I also wonder if you've also tried the corresponding lnt patch at D61598 that makes it possible to use this new functionality from lnt runtest test-suite?

I don't think I've run into any further issues (that are the test-suite's fault) since applying your patch.

Thanks for pointing me to that patch for LNT. I will see if it works for me. Until yesterday I was just invoking cmake directly, not via LNT, but now I need LNT's CSV-making powers.

Thanks for the feedback Sam!

Thanks for upstreaming this, Tim.

I haven't created any tests for this yet - I thought I'd first try and get feedback on whether this approach seems right before I spent time learning about how to get the test-suite unit/regression tests set up.

Hi Mandeep,

Hi Mandeep,

This intrinsic got added to gcc a while ago and should become available in the upcoming gcc 9 release.
In gcc however, the prototype of the intrinsic is slightly different (see https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html):
type __builtin_speculation_safe_value (type val, type failval)
It provides a second optional argument "failval". From the gcc documentation: "The function may use target-dependent speculation tracking state to cause failval to be returned when it is known that speculative execution has incorrectly predicted a conditional branch operation."
So, when implementing the intrinsic using a speculation barrier such as lfence, that failval argument doesn't have any effect. However, when lowering the intrinsic using speculation tracking similar to how that's used in SLH, this failval parameter is used to return a non-zero value on miss-speculation, in case the developer prefers that over the default zero value.

Thanks for picking this up, Zola!

Hi Tim,

In D57806#1415955, @abrown wrote:

Thanks for the review. I don't have committer rights; could you merge this for me or point me to how to get access?

LGTM, thanks for fixing this!

This seems quite obvious.
Typically when we change the behaviour of code, we aim to add a unit/regression test to check that indeed the code now has the intended behaviour (and mostly to make sure future changes do not regress on that expected behaviour).
That being said, this is a change to debug output, for which we typically do not add regression tests.

Updated approach to use the register scavenger to find an available temporary register. In the rare case when no temporary register is available, fall back to inserting a full speculation barrier.

In D55929#1358920, @zbrid wrote:

Hi Kristof,

Thanks for writing this code! I had an easy time understanding what you were doing.

I was discussing this SLH implementation with Chandler and he suggested that it may be useful to write a design doc similar to the one for the x86 implementation, so other people in the community can understand and discuss the current/future design with the ARM specific details laid out. What do you think?

In D54896#1354951, @zbrid wrote:

Hi Kristof,
Sorry about this late review. I wanted to make sure that I understood your implementation of SLH for ARM, so I took a look and made a few comments with some questions on this first patch. Let me know your thoughts. I'm planning to take a look at the other commit you made a few days ago related to SLH too. Hopefully I didn't make too many comments that were already addressed in the follow up commit.

Any feedback on the idea of an alternative, much lighter Conduit API client (since we only use a subset of Phab features) where it's also easier to (by default) hook linters or various other tools to? Not sure how others feel about Arcanist especially considering it covers a massive set of APIs beyond what's commonly used here and a local PHP installation just to run it is often undesirable (A simpler one-file client in Python should suffice, especially considering that many are changing their workflows due to the Git migration).

In D52803#1349005, @aditya_nandakumar wrote:

By default the CSE is enabled during IRTranslator and Legalizer now (disable with -enable-cse-in-legalizer/irtranslator=0).

I naively wonder if unconditionally enabling a CSE optimization even at -O0 is going to lead to a poorer debug experience in some cases?

Fix 2 issues flagged by -verify-machineinstrs when testing this patch on more code.

This updated diff addresses Oliver's final comment, namely about what to do when the program uses X16, e.g because of use of inline assembly specifically requesting to use X16.
Besides all the options I came up with previously, there is a 4th option: prevent speculation by inserting DSB SYS/ISB instruction pairs. Conceptually this is not unlike using lfence in X86SpeculativeLoadHardening.
I believe the pros/cons of this approach are (compared to the 3 options I listed previously):
Pros:

• A relatively simple implementation.
• Still keeping the advantages of doing speculation hardening very late.
• No silent non-protected code.
• This alternative protection mechanism is expected to only be needed for a very small amount of code.

Cons:

• This likely has higher overhead than if we could still use a data flow mechanism to track when control flow miss-speculation happens.

There currently isn't even a user interface to reserve X16.

X16 can be reserved by the user using inline assembly, either with a clobber or named register variable. I can think of a few cases where this might happen in real code:

D51432 uses it in libunwind to implement unwinding through functions using return-address signing.
Inline assembly which contains a function call will need to clobber X16 and X17.
If moving this pass to before register allocation would add a lot of extra complexity, maybe this could also be solved by copying the taint into SP before each inline asm block, and back out afterwards, like we currently do for calls?

• Addressing most of Oliver's comments.

LGTM now. I'm not an expert on the clang attribute mechanics, so am relying on Aaron's judgement/review for that part.
Thanks Zola!

In D54555#1301084, @aaron.ballman wrote:

Does this hardening impact the ABI in any way? e.g., do we have to do anything special to handle calls through function pointers where the bound function pointer is marked with this attribute?

This patch looks fine to me, assuming the TSV110 core implements Armv8.2 including the optional extensions ARMv8.2-FP16, ARMv8.2-DotProd, ARMv8.2-FHM and SPE.

Add a sentence on statuses involved when triaging.

I guess you're mainly asking review on this to get opinions on the approach to introduce new pseudo instructions just to avoid cycles during DAG combining and/or lowering?
From the patch, I furthermore guess that introducing a new pseudo leads to quite a bit of code duplication/violations of the "don't-repeat-yourself" principle in the instruction matching patterns?

In D53121#1261408, @srhines wrote:

This LGTM, but we should wait to hear from Kristof before submitting.

Hi Aaron,

In D51862#1229129, @danilaml wrote:

I'm also using pycodestyle 2.4.0. The error/warning was not about raw strings in regexps, rather illegal escape sequences, i.e.:

.\lnt\server\db\regression.py:58:20: W605 invalid escape sequence '\d'

I think using raw strings is better than using something like \\d.

Btw, I doubt that I can commit to llvm repo, so I need somebody to commit this for me. Thanks!

I am as excited by this as the other reviewers.
Thank you very much for this, Matthias!

I'm not an expert on many of the areas touched by this patch, but it looks fine from me from a high-level point-of-view, modulo a few nits I have on a few comments.

update diff with full context