Displaying 11 results from an estimated 11 matches for "avx128".
Did you mean:
aes128
2017 Nov 01
5
RFC: [X86] Introducing command line options to prefer narrower vector instructions even when wider instructions are available
Hello all,
I would like to propose adding the -mprefer-avx256 and -mprefer-avx128
command line flags supported by latest GCC to clang. These flags will be
used to limit the vector register size presented by TTI to the vectorizers.
The backend will still be able to use wider registers for code written
using the instrinsics in x86intrin.h. And the backend will still be able to
use...
2017 Nov 03
2
RFC: [X86] Introducing command line options to prefer narrower vector instructions even when wider instructions are available
...Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Wed, Nov 1, 2017 at 7:35 PM, Craig Topper via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello all,
>>
>>
>>
>> I would like to propose adding the -mprefer-avx256 and -mprefer-avx128
>> command line flags supported by latest GCC to clang. These flags will be
>> used to limit the vector register size presented by TTI to the vectorizers.
>> The backend will still be able to use wider registers for code written
>> using the instrinsics in x86intrin.h. And t...
2017 Nov 07
2
RFC: [X86] Introducing command line options to prefer narrower vector instructions even when wider instructions are available
On Fri, Nov 3, 2017, at 05:47, Craig Topper via llvm-dev wrote:
> That's a very good point about the ordering of the command line options.
> gcc's current implementation treats -mprefer-avx256 has "prefer 256 over
> 512" and -mprefer-avx128 as "prefer 128 over 256". Which feels weird for
> other reasons, but has less of an ordering ambiguity.
>
> -mprefer-avx128 has been in gcc for many years and predates the creation
> of
> avx512. -mprefer-avx256 was added a couple months ago.
>
> We've had an in...
2017 Nov 09
2
RFC: [X86] Introducing command line options to prefer narrower vector instructions even when wider instructions are available
...t;
>> On Fri, Nov 3, 2017, at 05:47, Craig Topper via llvm-dev wrote:
>> > That's a very good point about the ordering of the command line options.
>> > gcc's current implementation treats -mprefer-avx256 has "prefer 256 over
>> > 512" and -mprefer-avx128 as "prefer 128 over 256". Which feels weird for
>> > other reasons, but has less of an ordering ambiguity.
>> >
>> > -mprefer-avx128 has been in gcc for many years and predates the creation
>> > of
>> > avx512. -mprefer-avx256 was added a coupl...
2017 Nov 11
2
RFC: [X86] Introducing command line options to prefer narrower vector instructions even when wider instructions are available
...a llvm-dev wrote:
>>>> > That's a very good point about the ordering of the command line
>>>> options.
>>>> > gcc's current implementation treats -mprefer-avx256 has "prefer 256
>>>> over
>>>> > 512" and -mprefer-avx128 as "prefer 128 over 256". Which feels weird
>>>> for
>>>> > other reasons, but has less of an ordering ambiguity.
>>>> >
>>>> > -mprefer-avx128 has been in gcc for many years and predates the
>>>> creation
>>>&g...
2017 Nov 12
2
RFC: [X86] Introducing command line options to prefer narrower vector instructions even when wider instructions are available
...t; > That's a very good point about the ordering of the command line
>>>>>> options.
>>>>>> > gcc's current implementation treats -mprefer-avx256 has "prefer 256
>>>>>> over
>>>>>> > 512" and -mprefer-avx128 as "prefer 128 over 256". Which feels
>>>>>> weird for
>>>>>> > other reasons, but has less of an ordering ambiguity.
>>>>>> >
>>>>>> > -mprefer-avx128 has been in gcc for many years and predates the
>>...
2017 Nov 13
3
RFC: [X86] Introducing command line options to prefer narrower vector instructions even when wider instructions are available
...;s a very good point about the ordering of the command line
>>>>>>> options.
>>>>>>> > gcc's current implementation treats -mprefer-avx256 has "prefer
>>>>>>> 256 over
>>>>>>> > 512" and -mprefer-avx128 as "prefer 128 over 256". Which feels
>>>>>>> weird for
>>>>>>> > other reasons, but has less of an ordering ambiguity.
>>>>>>> >
>>>>>>> > -mprefer-avx128 has been in gcc for many years and preda...
2017 Nov 13
2
RFC: [X86] Introducing command line options to prefer narrower vector instructions even when wider instructions are available
...ordering of the command line options.
>> > gcc's current implementation treats
>> -mprefer-avx256 has "prefer 256 over
>> > 512" and -mprefer-avx128 as "prefer
>> 128 over 256". Which feels weird for
>> > other reasons, but has less of an
>> ordering ambiguity.
>> >
>>...
2017 Nov 14
2
RFC: [X86] Introducing command line options to prefer narrower vector instructions even when wider instructions are available
...ommand line
>>>>>>>>>> options.
>>>>>>>>>> > gcc's current implementation treats -mprefer-avx256 has "prefer
>>>>>>>>>> 256 over
>>>>>>>>>> > 512" and -mprefer-avx128 as "prefer 128 over 256". Which feels
>>>>>>>>>> weird for
>>>>>>>>>> > other reasons, but has less of an ordering ambiguity.
>>>>>>>>>> >
>>>>>>>>>> > -mprefer...
2012 Oct 05
0
[LLVMdev] LLVM Loop Vectorizer
...this there can be an early machine function pass that sets up processor specific value in all of instructions in a loop vectorized by opt. This pass could look over options to see what is expected by the user and what is set to default etc. for example for newest x86-64 there is an option -mprefer-avx128 for gcc, which helps over 256AVX for several cases. The generic vector types in llvm could be put to use in opt.
-----Original Message-----
From: Hal Finkel [mailto:hfinkel at anl.gov]
Sent: Friday, October 05, 2012 9:39 PM
To: Ramanarayanan, Ramshankar
Cc: llvmdev at cs.uiuc.edu Mailing List; D...
2012 Oct 05
2
[LLVMdev] LLVM Loop Vectorizer
----- Original Message -----
> From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "Dibyendu Das" <Dibyendu.Das at amd.com>
> Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Friday, October 5, 2012 11:00:39 AM
> Subject: RE: [LLVMdev]