similar to: Question about llvm vectors

Hi Craig, Thank you very much for your answer. I did not want to discuss exactly the semantic and name of one operation but instead raise the question "would it be beneficial to have more vector builtins?". You wrote that the compiler will recognize a pattern and replace it by __builtin_ia32_haddps when possible, but how can I be sure of that? I would have to disassemble the generated

Hi, For now no. But I will add this three builtins to CGBuiltin.cpp. If you want, you can be a reviewer of this change. Regards Michael Zuckerman From: Craig Topper [mailto:craig.topper at gmail.com] Sent: Thursday, April 28, 2016 04:53 To: Zuckerman, Michael <michael.zuckerman at intel.com> Subject: Re: r267690 - [Clang][BuiltIn][AVX512]Adding intrinsics for vmovntdqa vmovntpd vmovntps

Hi , In the future, we will address this issue. Regards Michael Zuckerman From: Eric Christopher [mailto:echristo at gmail.com] Sent: Sunday, May 01, 2016 19:54 To: Zuckerman, Michael <michael.zuckerman at intel.com>; Craig Topper <craig.topper at gmail.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] r267690 - [Clang][BuiltIn][AVX512]Adding intrinsics for vmovntdqa

Thanks Serge! This means for every new intrinsic set, a systematic change should be made to LLVM to support the new intrinsic set, right? The change should include frontend change, IR instruction set change, as well as low level code generation changes? On Tue, Jan 9, 2018 at 12:39 AM, serge guelton via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > The vast majority of the

On Tue, Sep 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

Hi, > On Sep 1, 2020, at 10:26, Venkataramanan Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Alexandre, > > On Tue, 1 Sep, 2020, 2:21 pm Alexandre Bique, <bique.alexandre at gmail.com <mailto:bique.alexandre at gmail.com>> wrote: > On Tue, Sep 1, 2020 at 9:07 AM Venkataramanan Kumar > <venkataramanan.kumar.llvm at gmail.com

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

It did partially fix the issue but there is still one problem: llvm-objdump -sx gives: Version References: required from libpthread.so.0: 0x09691a75 0x00 05 GLIBC_2.2.5 0x09691972 0x00 09 GLIBC_2.3.2 0x09691973 0x00 07 GLIBC_2.3.3 0x06969192 0x00 12 GLIBC_2.12 required from libdl.so.2: 0x09691a75 0x00 21 GLIBC_2.2.5 required from libuuid.so.1: 0x09da27b0 0x00 19

Hi Venkat., Did you make progress with libmvec? Is there a chance that it lands into clang 11? Regards, Alexandre Bique On Tue, Sep 1, 2020 at 11:50 AM Venkataramanan Kumar <venkataramanan.kumar.llvm at gmail.com> wrote: > > Hi Florian, > > On Tue, 1 Sep, 2020, 3:11 pm Florian Hahn, <florian_hahn at apple.com> wrote: >> >> Hi, >> >> On Sep 1,

On Tue, Nov 10, 2020 at 7:01 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > How to find what is pulling libmvec? > > If you build a -DCMAKE_BUILD_TYPE=Debug lld, you can set a breakpoint > on lld/ELF/MarkLive.cpp:114 (ss->getFile().isNeeded) and check which > symbol makes > libmvec.so needed. I'm afraid this is going to far for me :) > > On the other

No. A shared object is needed if it is linked in (1)--no-as-needed mode or (2) after --gc-sections, a symbol referenced by a live input section is defined by the shared object. You'll need to check whether a symbol is defined by libmvec.so.1 On Mon, Nov 9, 2020 at 9:57 AM Alexandre Bique <bique.alexandre at gmail.com> wrote: > > On Mon, Nov 9, 2020 at 6:52 PM Fāng-ruì Sòng

Hi, Here is a small C++ program: vec.cc: #include <cmath> using v4f32 = float __attribute__((__vector_size__(16))); v4f32 fct1(v4f32 x) { return 1.0 / x; } v4f32 fct2(v4f32 x) { return __builtin_ia32_rcpps(x); } Which is compiled to: vec.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <_Z4fct1Dv4_f>: 0: c4 e2 79 18 0d 00 00 vbroadcastss

Hi Quentin, You are correct, I could manage to get clang to use vrcpps, but not in a satisfying way: clang++ -O3 -march=native -mtune=native \ -Rpass=loop-vectorize -Rpass-missed=loop-vectorize -Rpass-analysis=loop-vectorize \ -ffast-math -ffp-model=fast -ffp-exception-behavior=ignore -ffp-contract=fast \ -c -o vec.o vec.cc 0000000000000140 <_Z4fct4Dv4_f>: 140: c5 f8 53 c8

Hi all, At Sony we developed an LLVM based performance analysis tool named llvm-mca. We currently use it internally to statically measure the performance of code, and to help triage potential problems with target scheduling models. We decided to post this RFC because we are interested in the feedback from the community, and we also believe that other people might be interested in a tool like

This is partly an llvm question, and maybe partly C++. I am trying to make calls on code in the llvm infrastructure.(3.4.2) I appear to be missing some include files, but don't know how to track them down. I get compile errors on existing llvm header files, like the following two examples: -------------------------------------------------------------------------------- In file included

On Wed, Nov 11, 2020 at 10:37 PM Fāng-ruì Sòng <maskray at google.com> wrote: > If you want to drop symbol versioning with llvm-objcopy: > > * llvm-objcopy -R .gnu.version -R .gnu.version_r in.so out.so > * However, llvm-objcopy zeroes out the section content so at runtime glibc ld.so will error > "unsupported version 0 of Verneed record". > Thus we need to

On Tue, Sep 1, 2020 at 5:10 PM Florian Hahn <florian_hahn at apple.com> wrote: > The loop vectorizer does not really handle loops that already operate on vectors, so that is why the loop using v4f32 does not get widened. > > Arguably the user explicitly asked for 4xfloat vectors in the v4f32 version, so that is what gets generated. In my case I have tons of legacy code written for

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

Thank you very much for your help Fāng-ruì Sòng. I've tried various things like linking directly to libm-2.32 but it didn't work, it seems that libm-2.32 still pulls libmvec. I have the following linker flags: CLANG_LDFLAGS="-fuse-ld=lld -static-libstdc++ -static-libgcc -fvisibility=hidden -fdata-sections -ffunction-sections" CLANG_LDFLAGS="$CLANG_LDFLAGS

=== PROBLEM === (See this bug https://llvm.org/bugs/show_bug.cgi?id=26445) IR contains code for loading a float from float * and storing it to a float * address. After canonicalization of load in InstCombine [1], new bitcasts are added to the IR (see bottom of the email for code samples). This prevents select speculation in SROA to work. Also after SROA we have bitcasts from int32 to float.