Displaying 7 results from an estimated 7 matches for "vbits".
Did you mean:
bits
2011 Nov 17
2
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
...;::iterator>
> + vpp_iterator_pair;
http://llvm.org/docs/CodingStandards.html#ll_naming
"Type names (including classes, structs, enums, typedefs, etc) should be
nouns and start with an upper-case letter (e.g. TextFileReader)."
> + void getCandPairs(unsigned vBits, BasicBlock&BB,
> + std::multimap<Value *, Value *> &candPairs,
> + std::vector<Value *> &pairableInsts);
"Variable names should be nouns (as they represent state). The name
should be camel case, and start with an up...
2011 Nov 21
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
...p_iterator_pair;
>
> http://llvm.org/docs/CodingStandards.html#ll_naming
>
> "Type names (including classes, structs, enums, typedefs, etc) should be
> nouns and start with an upper-case letter (e.g. TextFileReader)."
>
>
> > + void getCandPairs(unsigned vBits, BasicBlock&BB,
> > + std::multimap<Value *, Value *> &candPairs,
> > + std::vector<Value *> &pairableInsts);
>
> "Variable names should be nouns (as they represent state). The name
> should be camel c...
2011 Nov 16
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
Tobias, et al.,
Attached is the my autovectorization pass. I've fixed a bug that appears
when using -bb-vectorize-aligned-only, fixed some 80-col violations,
etc., and at least on x86_64, all test cases pass except for a few; and
all of these failures look like instruction-selection bugs. For example:
MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with
an error: error in
2011 Nov 15
3
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
Tobias,
I've attached the latest version of my autovectorization patch. I was
able to add support for using the ScalarEvolution analysis for
load/store pairing (thanks for your help!). This led to a modest
performance increase and a modest compile-time increase. This version
also has a cutoff as you suggested (although the default value is set
high (4000 instructions between pairs) because
2019 Sep 30
3
Adding support for vscale
On Tuesday, October 1, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > I've posted two patches on Phabricator to add support for VScale in LLVM.
Excellent!
> >
> > A brief recap on `vscale`:
> > The scalable vector type in
2019 Oct 01
3
Adding support for vscale
...rdless of whether some operations process
> only a subset of them.
ok so this *might* be answering my question about vscale being
relate-able to a function parameter (the latter of the c examples), it
would be good to clarify.
> In RVV terms that means it's related not to VL but more to VBITS,
> which is indeed a constant (and has been for many months).
ok so VL is definitely "assembly-level" rather than something that
actually is exposed to the intrinsics. that may turn out to be a
mistake when it comes to data-dependent fail-on-first capability
(which is present in a *D...
2019 Oct 01
2
Adding support for vscale
...y a static approach.
>
>> ok so this *might* be answering my question about vscale being
>> relate-able to a function parameter (the latter of the c examples), it
>> would be good to clarify.
>>
>>> In RVV terms that means it's related not to VL but more to VBITS,
>>> which is indeed a constant (and has been for many months).
>>
>> ok so VL is definitely "assembly-level" rather than something that
>> actually is exposed to the intrinsics. that may turn out to be a
>> mistake when it comes to data-dependent fail-o...