- User Since
- Oct 19 2012, 12:57 AM (252 w, 2 d)
Fri, Aug 18
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.
Thu, Aug 17
Curiosity: Do you have a use for this in-tree or just off-tree?
Tue, Aug 15
Ok, LGTM. Thanks!
Mon, Aug 14
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.
Sat, Aug 12
Yup. LGTM. Thanks!
There are two patches here, please split them.
Fri, Aug 11
Thu, Aug 3
Sorry, long holidays... :)
This makes sense to me. LGTM. Thanks!
Fri, Jul 28
LGTM too. Thanks!
Tue, Jul 25
Mon, Jul 24
Sun, Jul 23
Fri, Jul 21
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?
Jul 7 2017
Jul 6 2017
Jul 5 2017
Jul 1 2017
Changing the default to stable removes any concerns about zorg. I quite like this change as I do agree that all should be all. I also don't like the -W distinction, and this is where this change makes sense.
Jun 30 2017
Jun 26 2017
Jun 6 2017
@srhines: Do you need Android to *always* be 64-bit, even if someone forces aapcs with it?
I don't see why we should force the target, given that this is a CodeGen test, should worr (and be tested) on all targets.
Just FYI, when you submit a patch, use "git diff -U999" so that we can see the context in the web interface. Makes it easier to review. :)
Where is this failing?
Jun 5 2017
Jun 2 2017
Makes sense to me. But now that "generic" is the default, it'll impact all cores equally, so I'll let other people comment before approving.
May 31 2017
May 30 2017
A few more comments... :)
May 26 2017
Hi, can you please re-share the patch with more context?
May 25 2017
Silly inline comment, but otherwise, LGTM. Thanks!
May 24 2017
May 23 2017
Ok, I think it's good as it is. Looking forward to more patches in this area. :)
Approving, so that when Steve does the same, the review is free to commit.
May 22 2017
Some initial comments...
Wait, Stephen had a concern, we need his feedback on my reply before approving.
Hi Ayal, sorry for the delay. Can you commit the plan doc separately?
May 21 2017
Just to be clear, I'm not *against* the idea of an intrinsic, nor I'm pushing this patch for any personal/professional agenda. I hope I have made that perfectly clear on my previous reviews on the same patches before.
May 20 2017
Right, I think this is a useful thing to have, but it needs a better plan.
May 19 2017
May 18 2017
May 17 2017