OK, so I fixed this last night in r251388. I decided to go with "," means
"and" and "|" means "or" and go from there. If we need a more complicated
syntax we'll go back to the drawing board :)
-eric
On Sun, Oct 18, 2015 at 9:57 AM Craig Topper wrote:
> Interestingly, gcc doesn't get this right
Interestingly, gcc doesn't get this right either
*test.cpp:7:64:* *error: *‘*__builtin_ia32_xorpd256_mask*’ needs isa option
-m32 -mavx512dq -mavx512vl
I'm not even sure why it bothered to list -m32.
If you then give it -mavx512dq without -mavx512vl it proceeds to throw
internal compiler errors
Sure, but if someone is planning on doing this for ARM there's some work in
the ARM TargetInfo that needs to be done :)
-eric
On Fri, Oct 16, 2015 at 3:24 PM Justin Bogner wrote:
> Looks like we'll need "and" for ARM's builtins as well - several require
> things like neon+fp16 or neon+vfp4.
>
>
Looks like we'll need "and" for ARM's builtins as well - several require
things like neon+fp16 or neon+vfp4.
Eric Christopher writes:
> Right. My current direction is going to be:
>
> "foo+bar" we can represent as "and"
> "foo,bar" we'll continue to represent as "or"
>
> this will lead to things
Right. My current direction is going to be:
"foo+bar" we can represent as "and"
"foo,bar" we'll continue to represent as "or"
this will lead to things like (possibly):
"foo+bar, baz" - "either foo and bar, or baz."
-eric
On Fri, Oct 16, 2015 at 11:41 AM Justin Bogner
wrote:
> Hm. Well, suppo
Hm. Well, supporting both "and" and "or" combinations here sounds like
an unpleasant path to go down. I guess the question is, which is
weirder?
- With fma, we have fma4 which is basically a synonym as far as
intrinsics go - some chips have 3-argument versions and some have 4,
but I don't thin
That's the way Intel defined the CPUID bits.
I definitely see things like this in the backend
let Predicates = [HasBWI, HasVLX]
and the comma there does mean AND so at least some of it is enforced.
On Fri, Oct 16, 2015 at 12:35 AM, Eric Christopher
wrote:
> Also, is the backend enforcing this
Also, is the backend enforcing this? I.e. I should be able to construct a
testcase that has avx512vl or avx512bw that will fail to select yes?
-eric
On Fri, Oct 16, 2015 at 12:34 AM Eric Christopher
wrote:
> Lovely. Cc'ing Justin here. We'll need to figure out some change for these
> builtins h
Lovely. Cc'ing Justin here. We'll need to figure out some change for these
builtins here if we need to have and as well as or.
(Why on earth are these builtins subject to two separate features? *sigh*
It's ridiculous.)
-eric
On Thu, Oct 15, 2015 at 11:59 PM Craig Topper
wrote:
> Correct you av
Correct you avx512vl means it support 128 and 256-bit vectors. avx512bw
means it supports byte and word elements. So you actually need both.
On Thu, Oct 15, 2015 at 11:57 PM, Eric Christopher
wrote:
> The comma separated list is currently represented as "one of these". I
> couldn't parse your fi
The comma separated list is currently represented as "one of these". I
couldn't parse your first sentence, for the avx512 ones are you saying that
it requires both and not just one of the options?
-eric
On Thu, Oct 15, 2015 at 11:55 PM Craig Topper
wrote:
> So for the AVX512 ones that list 2 fe
So for the AVX512 ones that list 2 features those features are both
required, but for FMA you need either one of the features but not both.
What is the comma separated list currently implemented as?
On Thu, Oct 15, 2015 at 3:46 PM, Eric Christopher via cfe-commits <
cfe-commits@lists.llvm.org> wro
Author: echristo
Date: Thu Oct 15 17:46:02 2015
New Revision: 250470
URL: http://llvm.org/viewvc/llvm-project?rev=250470&view=rev
Log:
Fix the subtarget features required by some x86 builtins.
Update the fma builtins to be fma/fma4 until some we can find some
documentation either way.
Update a c
13 matches
Mail list logo
