- User Since
- Jan 23 2017, 12:28 AM (191 w, 4 d)
Fri, Sep 4
Wed, Sep 2
Fri, Aug 28
TODO: adapt to changes of get.active.lane.mask.
Thu, Aug 27
- rebased (onto clang-formatting commit for the SDA)
Bug fix: DivLoopExit's loop may be nullptr
- addressed reviewer comments, clean-up, tidy
Wed, Aug 26
Thanks for dropping by!
Have you considered using the ext_vector_type attribute instead of vector_size for this? That would have a couple of advantages:
- It's not a GCC attribute, so there's no risk that GCC would give different meaning to the same syntax (such as using one byte per vector element, which would be the natural meaning for a vector of bool as an extension of existing functionality).
- ext_vector_type takes as an argument a number of elements, not a size in bytes, so you could support vectors of non-multiple-of-8 bools.
Whichever solution is going to land in Clang, we will end up in the situation that Clang supports bool vectors and GCC does not. Any code that uses this feature and is supposed to compile with GCC will need some #ifdef guard. This is why i am not too worried about (ab-)using the vector_size attribute for this.
Aug 25 2020
NFC. Make clang-tidy happy.
- made bool-vector layout target dependent (one byte per bool element on Hexagon, one bit everywhere else).
- Added hvx-specific debug info test.
- Updated docs.
Aug 24 2020
The Hexagon builtins explicitly require bool vectors to have 8-bit wide bool elements. That clashes with our new vector type because bool vectors in builtin functions and vector_size bool vectors have the same internal representation in Clang. However, AFAIK Hexagon is the only target that actually need 8-bit bools. I see two possible ways out of this:
Aug 21 2020
Thanks for your comments! Maybe you know people who could review the CodeGen side of this..?
- Allow comparisons on boolean vectors.
- Restored result type for vector comparisons on other types.
- Added operator, alignment and constexpr tests.
Aug 20 2020
Aug 17 2020
Please look into the lint comments. Otw, LGTM.
Aug 14 2020
Aug 13 2020
- Fixed type printing & added type printing test.
Aug 11 2020
Aug 10 2020
- It would be very helpful put the stress on the token value when it comes to the question which threads converge on the same static instruction. Does the token encode only the instance, does it include the static instruction 'id', ie can two instructions return the same token value?
- Not sure about llvm.experimental.constrained.anchor: ie, the current non-definition (it is the 'implementation-defined') invites in almost arbitrary semantics (depending on how the token value comes about).
Aug 7 2020
Feel free to commit something like this without review
Aug 6 2020
- Fixed debug info representation for bool vectors (and added debug info test).
- Interpret 8*N with the N of vector_size(N) as the numbers of bool elements of the vector.
Nice! LGTM :)
Aug 4 2020
Thanks for the feedback!
Planned change: interpret the N in vector_size(N) as the number of bytes in the type, such that, for example, a vector_size(2) bool vector holds 16 bits
Aug 3 2020
Jul 31 2020
Jul 30 2020
This has been upstreamed for the most part.
- Style updates
Updated clang test
Jul 28 2020
- Implement EmitFromMemory
Thanks for the comments so far.
Jul 27 2020
Nit. LGTM otherwise.
Jul 23 2020
Jul 6 2020
I'd say you can commit a minor NFC like this one (in particular on a code base you have authored for the most part) without review.
Please consider the coding style suggestions (in particular for lower-casing function names). Otw, LGTM.
Jul 1 2020
Jun 29 2020
Jun 24 2020
Basic Clang support for VE is now upstream: rG96d4ccf0
Jun 23 2020
Jun 19 2020
Jun 18 2020
Jun 17 2020
Jun 16 2020
Exactly. With this patch %x.uni is marked as join divergent even though it is uniform: In its present form the patch solves one issue at the cost of precision.
I am a bit surprised this is necessary. Actually, join divergence in bb3 should come about as a result of propagateLoopDivergence for the [bb1, bb2] loop and not immediately because it is a divergent exit.
Also, a divergent loop exit does not automatically become join divergent, eg:
Jun 15 2020
You could short cut this by calling propagateBranchDivergence right away instead of using DeferredTerminators (and mark the terminator as divergent). That's in the same spirit as calling pushUsers on a regular instruction since sync dependence is just a different kind of dependence.
Jun 10 2020
LGTM with one minor nit. Thanks!
Jun 9 2020
Jun 8 2020
Just one nit.
- Removed PredicatedInstruction, which isn't strictly necessary for this patch.