[PATCH] D92445: [PowerPC] Add powerpcle target.
q66 added a comment. I am interested in this, since we are currently bootstrapping an entire ppcle userland in our distribution (glibc and musl) - we already have everything generally working (on ppc64le host), with llvm being a notable blocker for some things - so i will be testing this in near future Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92445/new/ https://reviews.llvm.org/D92445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D92445: [PowerPC] Add powerpcle target.
q66 added a comment. we are also interested in running this on "true" 32-bit hardware eventually, so not restricting to POWER7 would be a good thing, potentially Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92445/new/ https://reviews.llvm.org/D92445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D92445: [PowerPC] Add powerpcle target.
q66 added a comment. I've tested the patch (applied to LLVM11) and can confirm it works. There have been some changes/fixes I needed to do, which I already reported on IRC, so I will not include them here (Bdragon28 should just be able to apply them and push them out) Right now, I have a full ppcle Linux userland (which can fully compile itself, so it's self-hosted), I will be making binary packages available soon (source is already available through the Void Linux project) so anyone with a ppc64le kernel with a couple of fixes (also available through Void) should be able to run a full 32-bit LE environment Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92445/new/ https://reviews.llvm.org/D92445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D137511: [PPC] Undefine __ppc64__ to match GCC
q66 added a comment. The `__ppc__` macro should get the same treatment. That said, I believe there are instances of both macros being used across the LLVM codebase, and those cases are valid, so that should also be updated (one instance i know of is the limits header of libcxx, there are likely more) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137511/new/ https://reviews.llvm.org/D137511 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D106120: [PowerPC] Implement vector bool/pixel initialization under -faltivec-src-compat=xl
q66 added a comment. Hi, this warning also affects GCC-style vectors: e.g. typedef int myivec __attribute__((vector_size(16)); typedef float myfvec __attribute__((vector_size(16)); const myvec ret = (myfvec1 == myfvec2); // will issue a warning Should it? This means different semantics between targets without explicitly using AltiVec vectors. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D106120/new/ https://reviews.llvm.org/D106120 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D106120: [PowerPC] Implement vector bool/pixel initialization under -faltivec-src-compat=xl
q66 added a comment.
and indeed, it affects semantics too:
/tmp$ clang++ test.cc -o test -faltivec-src-compat=xl
/tmp$ ./test
b
b
b
/tmp$ clang++ test.cc -o test -faltivec-src-compat=gcc
/tmp$ ./test
Dv4_i
Dv4_i
Dv8_s
/tmp$ clang++ test.cc -o test -faltivec-src-compat=mixed
test.cc:10:20: warning: Current handling of vector bool and vector pixel
types in this context are deprecated. The default behaviour will soon change to
that implied by the '-altivec-compat=xl' option
[-Wdeprecated-altivec-src-compat]
auto cmp = (v1 == v2);
^
test.cc:12:22: warning: Current handling of vector bool and vector pixel
types in this context are deprecated. The default behaviour will soon change to
that implied by the '-altivec-compat=xl' option
[-Wdeprecated-altivec-src-compat]
auto pcmp = (pv1 == pv2);
^
2 warnings generated.
/tmp$ ./test
Dv4_i
b
Dv8_s
/tmp$ cat test.cc
#include
#include
typedef float simd4f __attribute__((vector_size(16)));
int main() {
simd4f v1, v2;
vector float fv1, fv2;
vector pixel pv1, pv2;
auto cmp = (v1 == v2);
auto acmp = (fv1 == fv2);
auto pcmp = (pv1 == pv2);
printf("%s\n", typeid(cmp).name());
printf("%s\n", typeid(acmp).name());
printf("%s\n", typeid(pcmp).name());
}
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D106120/new/
https://reviews.llvm.org/D106120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D106120: [PowerPC] Implement vector bool/pixel initialization under -faltivec-src-compat=xl
q66 added a comment. On x86_64, the program predictably prints `Dv4_i`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D106120/new/ https://reviews.llvm.org/D106120 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D106120: [PowerPC] Implement vector bool/pixel initialization under -faltivec-src-compat=xl
q66 added a comment. Well, I'm more concerned about the actual semantics - as I see it, when using generic vectors, they should be unaffected by the comparison behavior of AltiVec vectors, which is not the case when you set the mode to `xl`. If the semantics are affected, it means creating a massive pain for libraries that use generic vectors without caring what platform they are in (since they will get a vector as a result of comparison on x86_64, but a bool on PowerPC). And since the behavior can be switched with a compiler flag, they don't even have a reasonable way to make this conditional in the code. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D106120/new/ https://reviews.llvm.org/D106120 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D106120: [PowerPC] Implement vector bool/pixel initialization under -faltivec-src-compat=xl
q66 added a comment. I see. Is there a way to compile-time-detect whether one is getting the XL behavior? This is still a potential concern for things that expose vector ops in public headers. There should be a macro of some kind to detect this at compile time and follow the XL semantics when needed. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D106120/new/ https://reviews.llvm.org/D106120 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
