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 nea
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/D92
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
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
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 b
q66 added a comment.
and indeed, it affects semantics too:
/tmp$ clang++ test.cc -o test -faltivec-src-compat=xl
/tmp$ ./
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
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 ma
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 n
