Includes new built-in, conversion of built-in to target-independent intrinsic and update in the header file. Tests are also updated. There is a second part in the backend for which I will post a separate code-review. BACKEND PART SHOULD BE COMMITTED FIRST.
Diff Detail
Event Timeline
lib/Headers/altivec.h | ||
---|---|---|
136 | I thought we were going to change the guard here to VSX rather than __POWER8_VECTOR. | |
test/CodeGen/builtins-ppc-altivec.c | ||
3 | Just a minor nit. Please indent the continuation lines for readability. | |
8 | I would have thought that we already have a diagnostic test case for the missing -faltivec, but if we don't, thanks for adding it. | |
85 | I am not recommending you change anything here, just want to point out that there's a potential concern with adding diagnostic test cases in with functional ones (and yes, I know we have lots of this already). Namely, the concern is that the diagnostic may go away as we add more code to the test case and the particular error you're looking for goes past the error threshold (I think the default is 20 errors). | |
test/CodeGen/builtins-ppc-p8vector.c | ||
76–79 | I think that without asserts, clang sometimes gives temporary variables names rather than numbers. I'd recommend getting rid of the regex for the argument to @llvm.fabs.* so that you don't get into a weird situation where some build bot somewhere fails due to this change. |
lib/Headers/altivec.h | ||
---|---|---|
136 | I want to go through the file separately, check for similar inaccuracies, and fix everything of that kind in one separate commit. This may also require moving test cases between different files. So I do not want to mix it with another submission. | |
test/CodeGen/builtins-ppc-altivec.c | ||
8 | No we don't. I spent some time looking for it in the existing test cases and did not find anything. | |
85 | Would it address your concern if I add "-ferror-limit 0" to the command line? | |
test/CodeGen/builtins-ppc-p8vector.c | ||
76–79 | That pattern is used in other tests. (You can see that in the one right above this one.) But I am fine with changing it to a more general regex like {{.*}}. (I can also remove it but I really wanted to close the parenthesis :) |
All of my comments are just nits and shouldn't hold up approval. As far as I can tell this looks fine, but I'll let the LGTM come from Kit or Hal.
lib/Headers/altivec.h | ||
---|---|---|
136 | That would be great! Thank you. | |
test/CodeGen/builtins-ppc-altivec.c | ||
85 | I think that's a great idea and good general guidance for test cases of this type. BTW, no need to post another review for this - just change it in the commit once this patch is approved. | |
test/CodeGen/builtins-ppc-p8vector.c | ||
76–79 | I see what you mean, it's in the previous CHECK pattern. You should be safe keeping this in. However, I'd recommend that you try a build without asserts (especially for FE changes) just to make sure things don't behave differently. The only reason I bring it up is because I've been burned by that before :). |
added -ferror-limit 0 to the command line for no-altivec test.
fixed indentation of RUN commands
confirmed that all tests pass in a release and minrelsize build types
changed {{[0-9]*}} to {{.*}} (it was fine but no need to put a restrictions in the tests that we do not care about).
I thought we were going to change the guard here to VSX rather than __POWER8_VECTOR.