-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simd enablement #2945
Simd enablement #2945
Conversation
c32bb99
to
4db2a1c
Compare
Some discussion on horizontal intrinsics in LLVM here #903 (comment) which effect #2698 |
var v: u32 = 5;
var x = @splat(4, v); Can be changed to var v: u32 = 5;
var x = @Vector(4, v); ? |
src/ir.cpp
Outdated
@@ -12734,6 +12925,30 @@ static IrInstruction *ir_analyze_cast(IrAnalyze *ira, IrInstruction *source_inst | |||
return ir_analyze_widen_or_shorten(ira, source_instr, value, wanted_type); | |||
} | |||
|
|||
// widening of vectors | |||
// These are separate (while identical) as I am still not sure if this should not implicitely cast, | |||
// but only explicitely cast. (i.e. with @cast, or @as, or @Vector(4, i32)(foo)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need deciding on before merge?
Also, typo: "explicitly"
@data-man I don't like that because the capital letter |
7b458ce
to
520d2a3
Compare
5283ce3
to
e5292c0
Compare
ccad74f
to
8a76f14
Compare
ec301d1
to
44c9b47
Compare
See #3575 This PR implements array access of vectors to mean element access, but it's planned for that to be how to dereference a vector of pointers. I definitely am going to need this PR to be split into distinct smaller mergeable pieces. |
Yes I'm getting on it.
However I disagree with this proposal. I don't see what is wrong with the
way gcc-9 does it. I find your way confusing and unnecessarily different
from use of arrays.
As you discovered we can also make it work for odd-bit-widths if we change
llvm's bit packing of vectors (when written out) to pad like arrays are (I
don't really think this is a good idea however).
El vie., 1 nov. 2019 23:45, Andrew Kelley <[email protected]>
escribió:
… The first item would be *Array Accesses on Vectors*. If you open a PR
which only does this, I think we can get it merged swiftly. It seems
everything else in this PR depends on that feature.
See #3575 <#3575>
This PR implements array access of vectors to mean element access, but
it's planned for that to be how to dereference a vector of pointers.
I definitely am going to need this PR to be split into distinct smaller
mergeable pieces.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2945?email_source=notifications&email_token=AAD4W4UMOSFGHZWQ4UUN6ATQRUO2BA5CNFSM4IG4JEO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC4VHZA#issuecomment-549016548>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD4W4TNSIZYLIDK6UDWQP3QRUO2BANCNFSM4IG4JEOQ>
.
|
The lowering to |
If the integer fits in the significand (including the signed bit because of a edge case resulting from the difference between twos-complement and ones-complement), then cast to float is lossless.
This will allow alot more integer code to just magically work with vectors of integers, et cetera.
https://llvm.org/docs/LangRef.html#zext-to-instruction The ‘zext’ instruction takes a value to cast, and a type to cast it to. Both types must be of integer types, or vectors of the same number of integers. **The bit size of the value must be smaller than the bit size of the destination type, ty2.** The codegen was invalid.
Why ^, &, |, and ~ instead of !=, and, or, !? Consider: a() and b() If a() returns @vector(2, bool)([_]bool{false, false}), is b() run? How about if a() returns @vector(2, bool)([_]bool{false, true})? Making this defined would be slow, confusing, involve hidden control flow, and require putting the any() all() none() branching into the language. Even if a() and b() return "bool" these are different: a() and b() a() & b() ----- I would like to throw a good error when a vector of bools is passed, but the current architecture prevents that.
…unc), with safety checks. Finishing this depends on ziglang#1757. I'd rather not re-work ir_gen_node_raw for explicit casts (signed to unsigned, and safe narrowing casts) when that is upcoming. v2: @truncate can now take a scalar type
v2: do not emit libmvec when it does exist on the platform v3: do what is written above
Can't test for larger vectors (256-bit and 512-bit because of confusion with passing on stack and passing in registers (that don'y always exist). See ziglang#1481 (comment) ARM uses sret for vector arguments, and those are runtime. I don't understand what that assert was for.
This PR won't be merged, but I'm definitely interested in the smaller PRs that bring these commits in 1 at a time. I'll leave it up to @shawnl (or anyone else!) to track this fork and do the work of slowly upstreaming it. |
Not in scope:
Some stuff is blocked on #447.
While this mostly follows #903, there are some decisions that had to be made, the biggest one is support both bit-wise and bool operations on bools, because a() and b() is differn't from a() & b(), as if a() returns true the first will not run b() and the second will. This is explained in the commit.
TODO