search for: fveclib

...xities that will only get in the way of the standard discussion. Comments inline... On Wed, 12 Dec 2018 at 03:47, Francesco Petrogalli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Summary > ======= > > New `veclib` directives in clang I know this is not new but, why "fveclib"? From the review, I take this is the same as GCC's "mveclibabi", and if it is, why come up with a new name for the same thing? If it's not, what justifies implementing a different way of handling the same concept (vector math libraries), which is surely going to confuse a l...

Hi all, I am submitting the following RFC [1] to re-implement -fveclib via OpenMP constructs. The RFC was discussed during a round table at the last LLVM developer meeting, and presented during the BoF [2]. The proposal is published on Phabricator, for the purpose of keeping track of the comments, and it now ready for a review from a wider audience after being polish...

...and if the standard library is claimed to be available for any one translation unit in the linkage unit, it should be available for every other translation unit in the linkage unit. (Tangent, but related: I'm also wondering if this logic could/should be used to encode other TLI flags, such as -fveclib=<lib>. I.e., if one translation unit has -fveclib=Accelerate, does that imply that we can use that for the entire linkage unit? If there's a conflict, such as -fveclib=SVML in one and -fveclib=Accelerate in another, can we safely pick the first one arbitrarily?) >> One question t...

...available for any one translation unit in >> the linkage unit, it should be available for every other translation unit >> in the linkage unit. >> >> (Tangent, but related: I'm also wondering if this logic could/should be >> used to encode other TLI flags, such as -fveclib=<lib>. I.e., if one >> translation unit has -fveclib=Accelerate, does that imply that we can use >> that for the entire linkage unit? If there's a conflict, such as >> -fveclib=SVML in one and -fveclib=Accelerate in another, can we safely pick >> the first one ar...

I've tried to do: clang++ -O3 -march=native -mtune=native \ -Rpass=loop-vectorize,slp-vectorize -Rpass-missed=loop-vectorize,slp-vectorize -Rpass-analysis=loop-vectorize,slp-vectorize \ -ffast-math -ffp-model=fast -ffp-exception-behavior=ignore -ffp-contract=fast \ -c -o vec.o vec.cc But I've got no feedback. -- Alexandre Bique

In PR30403 we've been discussing how to encode -ffreestanding when using LTO. This bit is currently dropped during LTO because its only representation is in the TargetLibraryInfo created by clang ( http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258). The proposal is to introduce a module flag that we set in any translation unit compiled in hosted (i.e. -fno-freestanding)

On Wed, Oct 28, 2020 at 6:07 PM Fangrui Song <maskray at google.com> wrote: > > On 2020-10-28, Alexandre Bique via llvm-dev wrote: > >Hi, > > > >I wonder what is the right way to target an old glibc? > > > >I have a machine which is up to date (glibc 2.32 and clang+lld 10.0.1). > > > >So far I've been able to target older glibc by having a

...ommended way to do it? > > There is none. We can setup a different optimizer pass pipeline for LTO, but the target specific part (i.e. the backend) isn’t supposed to behave differently. > > This is an issue in general with LTO where options from the command line (like -fno-builtins, or -fveclib=xxxx) are not correctly propagated to LTO. > > What kind of behavior do you want to enable exactly? > > — > Mehdi >

Hi, I want to enable some target-specific functionality only if current build is 2nd LTO stage (i.e. optimizer called from plugin). What is best and recommended way to do it? --- With best regards, Konstantin

...1, 2020 at 9:07 AM Venkataramanan Kumar <venkataramanan.kumar.llvm at gmail.com> wrote: > Hi Alexandre, Hi Venkataramanan, > I am not sure if we can generate vector calls to GlibC libmvec. Is the support for libmvec on the roadmap? If not how to add it? > ./clang --autocomplete=-fveclib= This is amazing, thank you! I think it should be documented in clang auto vectorization documentation. Thank you very much, -- Alexandre BIQUE

...76103a000) libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007f2761031000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f2760eeb000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f2760d22000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f2761e3e000) [jenkins at archear build-clang.64]$ I even recompiled with -fveclib=none but it did not change anything. And I believe that -fveclib=mvec will start working with LLVM-12. I have no idea what pulls libmvec in. Regards, Alexandre Bique On Wed, Oct 28, 2020 at 6:23 PM Alexandre Bique <bique.alexandre at gmail.com> wrote: > > On Wed, Oct 28, 2020 at 6:07...

...gt; >>> There is none. We can setup a different optimizer pass pipeline for LTO, but the target specific part (i.e. the backend) isn’t supposed to behave differently. >>> >>> This is an issue in general with LTO where options from the command line (like -fno-builtins, or -fveclib=xxxx) are not correctly propagated to LTO. >>> >>> What kind of behavior do you want to enable exactly? >>> >>> — >>> Mehdi >>> >

.../usr/lib/libuuid.so.1 (0x00007f2761031000) > libm.so.6 => /usr/lib/libm.so.6 (0x00007f2760eeb000) > libc.so.6 => /usr/lib/libc.so.6 (0x00007f2760d22000) > /usr/lib64/ld-linux-x86-64.so.2 (0x00007f2761e3e000) > [jenkins at archear build-clang.64]$ > > I even recompiled with -fveclib=none but it did not change anything. > And I believe that -fveclib=mvec will start working with LLVM-12. > > I have no idea what pulls libmvec in. Recent libm.a and libm.so are actually linker scripts % cat /usr/lib/x86_64-linux-gnu/libm.a /* GNU ld script */ OUTPUT_FORMAT(elf64-x86-64)...

...There is none. We can setup a different optimizer pass pipeline for LTO, but the target specific part (i.e. the backend) isn’t supposed to behave differently. >>>>> >>>>> This is an issue in general with LTO where options from the command line (like -fno-builtins, or -fveclib=xxxx) are not correctly propagated to LTO. >>>>> >>>>> What kind of behavior do you want to enable exactly? >>>>> >>>>> — >>>>> Mehdi >>>>> >>> >

Illustrative Example: clang -fveclib=SVML -O3 svml.c -mavx #include <math.h> void foo(double *a, int N){ int i; #pragma clang loop vectorize_width(8) for (i=0;i<N;i++){ a[i] = sin(i); } } Currently, this results in a call to <8 x double> __svml_sin8(<8 x double>) after the vectorizer. This is 8-element...

Dear all, This RFC is a proposal to provide auto-vectorization functionality for user provided vector functions. The proposal is a modification of an RFC that I have sent out a couple of months ago, with the title `[RFC] Re-implementing -fveclib with OpenMP` (see http://lists.llvm.org/pipermail/llvm-dev/2018-December/128426.html). The previous RFC is to be considered abandoned. The original RFC was proposing to re-implement the `-fveclib` command line option. This proposal avoids that, and limits its scope to the mechanics of providing ve...

...llvm-dev wrote: >> Dear all, >> >> This RFC is a proposal to provide auto-vectorization functionality for user provided vector functions. >> >> The proposal is a modification of an RFC that I have sent out a couple of months ago, with the title `[RFC] Re-implementing -fveclib with OpenMP` (see http://lists.llvm.org/pipermail/llvm-dev/2018-December/128426.html). The previous RFC is to be considered abandoned. >> >> The original RFC was proposing to re-implement the `-fveclib` command line option. This proposal avoids that, and limits its scope to the mechanic...

...ll, >>>> >>>> This RFC is a proposal to provide auto-vectorization functionality for user provided vector functions. >>>> >>>> The proposal is a modification of an RFC that I have sent out a couple of months ago, with the title `[RFC] Re-implementing -fveclib with OpenMP` (see http://lists.llvm.org/pipermail/llvm-dev/2018-December/128426.html). The previous RFC is to be considered abandoned. >>>> >>>> The original RFC was proposing to re-implement the `-fveclib` command line option. This proposal avoids that, and limits its scope...

...rg] On Behalf Of Saito, Hideki via llvm-dev Sent: Friday, June 29, 2018 7:41 AM To: 'Saito, Hideki via llvm-dev' <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: [llvm-dev] [RFC][VECLIB] how should we legalize VECLIB calls? Illustrative Example: clang -fveclib=SVML -O3 svml.c -mavx #include <math.h> void foo(double *a, int N){ int i; #pragma clang loop vectorize_width(8) for (i=0;i<N;i++){ a[i] = sin(i); } } Currently, this results in a call to <8 x double> __svml_sin8(<8 x double>) after the vectorizer. This is 8-element...

...;>>>>> This RFC is a proposal to provide auto-vectorization functionality for user provided vector functions. >>>>>> >>>>>> The proposal is a modification of an RFC that I have sent out a couple of months ago, with the title `[RFC] Re-implementing -fveclib with OpenMP` (see http://lists.llvm.org/pipermail/llvm-dev/2018-December/128426.html). The previous RFC is to be considered abandoned. >>>>>> >>>>>> The original RFC was proposing to re-implement the `-fveclib` command line option. This proposal avoids that, and...