- User Since
- Oct 19 2012, 12:57 AM (260 w, 4 d)
Mon, Oct 16
Sun, Oct 15
Thu, Oct 12
Fri, Oct 6
Thu, Oct 5
I don't see anything terribly wrong in cleaning up between object emissions, but I'll let @t.p.northover and @peter.smith make sure this can't be done in a better way (like fixing the original patch), in which case, we might want at least an assert here.
Wed, Oct 4
Tue, Oct 3
Wed, Sep 27
Let's see how this goes... :)
I agree with Peter analysis and accept Saleem's solution as a compromise.
Fri, Sep 22
All similar VMOVs seem to have the same restriction, maybe we should update the whole lot at the same time?
Wed, Sep 20
Do you know what would be cool? A gcc-compatibility checker test... Something that would have the most problematic cases in C and asm files and would be compiled with multiple versions of gcc and clang triples, then compared.
Tue, Sep 19
Mon, Sep 18
Some more info on this. At the time Android did its implementation, the Linux kernel used to call do_cache_op, ignoring the return result and then returning zero. Now , it returns whatever do_cache_op returns, which ends up being a very long sequence of uses and definitions, boiling down to SVC.
tests? benchmarks results?
Ignore me, that was VSDOT... :)
Interesting, the Aarch32 PDF doesn't have SDOT/UDOT, only the AArch64 one...
The last ARMv8.2 manual I could find is from 31 March, but it says UDOT/SDOT will be documented later. Do you have an update on that?
Sep 13 2017
Sorry, pressed ctrl+enter by accident.
Digging it a bit, commit r203674 (reviewed by dsanders/bastien) introduced this part for Android ARM/MIPS.
Do you have any evidence that this behaviour was reached by design and not accident?
Sep 8 2017
I can't see anything immediately wrong with this patch, it looks trivial and correct. Moreover, if this was done because of a know problem (unlikely, given the commit it came from), we have the assert to help.
Sep 6 2017
We have dropped 39-bit testing a while ago and now that all AArch64 Linux kernels are moving to 48-bits, we don't need to support every possible variation.
Sep 4 2017
Sep 1 2017
As I said in D37374, please refrain from approving your own patches within minutes of posting. The community must be part of the process, and if people are not reviewing your patches as fast as you want, then there's either something wrong with the community (and we need to fix), or with your expectations.
Folks, please refrain from approving your own patches minutes after posting. This is not how open source is done. If you need review, let people review your patches. Peter's comment is a clear example on why this is important.
Aug 31 2017
Sorry, slight overlap. Please follow Ayal's comments before committing.
Sorry for the delay. It looks good to me now, thanks!
Aug 27 2017
Has there been an RFC on this?
Aug 23 2017
Aug 22 2017
Aug 21 2017
Aug 19 2017
Aug 18 2017
I'm happy with the patch, but I'll let @SjoerdMeijer approve.
This change seems to have nothing to do with adding core support but exposing features from CPU names.
Aug 17 2017
Curiosity: Do you have a use for this in-tree or just off-tree?
Aug 15 2017
Ok, LGTM. Thanks!
Aug 14 2017
Adding Eric, for consistency.
NFC. LGTM. Thanks!
Other than the one comment, LGTM. Thanks!
Submit as a different revision and we can discuss the merits there.
Aug 12 2017
Yup. LGTM. Thanks!
There are two patches here, please split them.
Aug 11 2017
Aug 3 2017
Sorry, long holidays... :)
This makes sense to me. LGTM. Thanks!
Jul 28 2017
LGTM too. Thanks!
Jul 25 2017
Jul 24 2017
Jul 23 2017
Jul 21 2017
So, it seems it was sphinx, but that was loop alignment, 4 bytes on A53, 8 bytes on A57, to do with the fetch alignment. Maybe this is a related issue. Why 16, though?
We found similar results on spec2k6 for aarch64 that we attributed to function alignment. Have you tried that? I need to dig the one culprit...
Jul 20 2017
Apologies, you had already sent all I needed. :)
Jul 19 2017
Jul 18 2017
Jul 17 2017
Setting aside from the fact that no one should ever be casting floating point to pointers, perhaps we shouldn't be even trying to do this transformation here, as I'm not sure this could have a guaranteed semantics in this case, and probably better to just bail the vectorisation?
Jul 14 2017
Jul 13 2017
The Clang counterpart was approved, this looks good, too. Thanks!
Jul 12 2017
@jmolloy Can you check this change, please?