User Details
- User Since
- Jun 18 2014, 12:59 AM (344 w, 3 d)
Wed, Jan 20
Just a few quick, knee-jerk-style, questions. My apologies if these are too simplistic or vague.
- Do you happen to have a pointer to some more documentation about this new Swift feature?
- I wonder if any features from other languages could also map to this IR/backend implementation? E.g. I haven't looked at how C++ co-routines are implemented, but would they be able to reuse this feature (assuming they would need a somewhat similar feature in mid- and back-end).
- As this seems to be introducing new ABI - do you have an idea of what the most appropriate ABI specification is this would be best documented in? Do I guess correctly that this is not a Darwin-only feature? If this is really swift-specific (i.e. it does not seem to be a good trade-off to have this mid/back-end feature support similar language features for multiple front-ends), I guess this is Swift-specific ABI. Do I guess correctly that there isn't really a specification for Swift-specific ABI - it's purely defined by its primary implementation?
- I just had one very detailed nit-pick comment on the documentation of frame layout - see specific comment.
Fri, Jan 15
My understanding is that AArch64 gnu_ilp32 support is present in mainline gcc, but not in mainline glibc nor in the mainline linux kernel. My understanding is also that it's unlikely that AArch64 gnu_ilp32 support will be added to mainline glibc or linux kernel anytime soon.
That makes me wonder how useful it is to support AArch64 gnu_ilp32 in mainline LLVM. It seems unlikely that it can be used for linux targets anytime soon. Are there non-linux targets using AArch64 gnu_ilp32?
Dec 19 2020
Dec 18 2020
Updated patch based on review comments + rebased to ToT
Updated patch based on review comments + rebased to ToT
Updated patch based on review feedback.
Dec 15 2020
LGTM too, thanks!
Dec 14 2020
Dec 10 2020
Dec 9 2020
Thanks for this.
The proposed changes all LGTM.
I did do a grep on the term 'master' in llvm/docs, and found quite a few more uses of 'master', especially in links.
The command I used was: grep -R master llvm/docs/
Just two examples are:
Dec 2 2020
Dec 1 2020
Nov 30 2020
Nov 28 2020
Oct 13 2020
Oct 9 2020
Thanks for this @pietroalbini !
This LGTM.
I'd also like to hear @mattdr's or @jfb's opinion before committing though.
Jul 6 2020
LGTM, thanks!
Jun 22 2020
This looks fine to me; I just have a number of nit picks.
The only part where I don't understand the code logic is around the comment starting with "If this is the final byte of a multi-byte sequence".
Jun 19 2020
Jun 18 2020
Jun 17 2020
Updated version based on @ostannard feedback.
Jun 16 2020
Jun 11 2020
This new revision fixes the root cause of GlobalISel asserting on an IndirectThunk: the IndirectThunk creation code was producing a MachineFunction with a slightly different structure than what gets produced from a naked function implemented in C code and processed by clang.
This fixes this by letting the IndirectThunk generator produce a MachineFunction structure that is the same as what gets produced by clang for an empty naked function written in C.
Jun 10 2020
Based on the review feedback that using X16 or X17 could be problematic since a linker can clobber those registers on a call, this patch goes for a different approach to achieve compatibility with BTI-enabled callees.
It simply moves the register to be called always to be in X16, and then does BR X16.
It seems it's simplest to do that unconditionally, as it may not always be easy to find out if the call target has been BTI-enabled.
The updated patch addresses Oliver's review comments.
Especially, it addresses the review feedback regarding potential clobbering of X16 or X17 when the call to the thunks go through a long veneer.
It addresses this by avoiding generating indirect calls that use X16 or X17.
Jun 9 2020
Thanks for the feedback!
I ended up pushing a fix for the racy tests in 7e6f891df85
I ended up pushing a fix for the racy tests in 7e6f891df85
Jun 8 2020
Jun 4 2020
I think I'd like the proposed organization better; but I only have a weak preference.
LGTM.
May 12 2020
May 8 2020
Apr 22 2020
LGTM
Apr 2 2020
Mar 30 2020
Assuming there is no change in output, LGTM.
Mar 25 2020
This seems OK to me.
I'd just remark that these days, I think most people using LNT to compile/run/benchmark test-suite use "lnt runtest test-suite" rather than "lnt runtest nt".
Therefore, maybe it'd be better if you'd look into how to make that working on the VE architecture (i.e. look at file lnt/tests/test_suite.py).
Mar 24 2020
LGTM. Thanks!
Mar 20 2020
Mar 17 2020
Feb 29 2020
Feb 28 2020
Feb 24 2020
As someone who isn't up to speed on the design of vector-function-abi-variant, this release note makes sense to me.
It'd probably be best though for this to be approved by someone who understands the design.
Feb 19 2020
After chatting with Oliver, he states that he did run ubsan before and after this change, and the undefined behaviour that was causing the segfaults is gone with this change.
(There are apparently other undefined behaviours flagged by ubsan, but they are unrelated).
I also don't know much about H264 decoding, but the removal of undefined behaviour as indicated by ubsan together with no change in output makes me believe this change is good enough for how the test-suite is used.
LGTM.