similar to: LLVM gold plugin do not add llvm instrinsics symbols to the linker symbol table

A couple questions/notes so I can understand better: Without -flto, a.o ends up with a reference to __exp_finite, which also would not be satifisfied out of libexp.a. Do you also have an implementation of __exp_finite in your libexp.a? Can you build with -fno-builtin, or -fno-builtin-exp etc? That results in a reference to __exp_finite in the .o bitcode (which of course has the same issue I

Hello Teresa, > Without -flto, a.o ends up with a reference to __exp_finite, That’s correct. > which also would not be satifisfied out of libexp.a. That’s not correct. Even if libexp.a would have __exp_finite, it wouldn’t be resolved from libexp.a, because of the behavior described in my first message. > Do you also have an implementation of __exp_finite in your libexp.a? No, I don’t

+pcc for thoughts On Fri, Mar 23, 2018 at 9:37 AM, Bakhvalov, Denis <denis.bakhvalov at intel.com > wrote: > Hello Teresa, > > > > > Without -flto, a.o ends up with a reference to __exp_finite, > > That’s correct. > > > > > which also would not be satifisfied out of libexp.a. > > That’s not correct. Even if libexp.a would have __exp_finite, it

> I'm trying to understand how the non-LTO case is supposed to work non-LTO case works because when linker starts it’s job all the llvm intrinsics are already lowered. > Right, which is why I am suggesting that it might be appropriate to build with -fno-builtin (or -fno-builtin-exp) here – > this solves the LTO issue as there will no longer be an llvm intrinsic in the bitcode Yes, I

Hi all, Many of us find ourselves spending a great chunk of time comparing LLVM IR dumps at various stages of compilation pipeline or after a given optimization pass. Said process can be extremely laborious, and this is especially true when comparing shaders or compute modules. Important semantic differences are often difficult to spot because of the irregular naming and ordering of instructions.

Hi, I'm from Intel compiler department. I am proposing the integration of a backend targeting Nios II processor architecture. Nios II is a 32-bit general-purpose RISC processor core designed specifically for the Altera family of FPGAs. All information at about Nios II can be found at Altera website https://www.altera.com/products/processors/support.html, including the current ISA

This might be a very beginner question, but I'm looking for an example for something that I have never done. Suppose that I wanted to express actions with respect to lifted semantics of CPU instructions to an intermediate representation, BAP IL or LLVM IR. How might I go about providing a Backus Naur Form specification and then dynamically interpreting those lifted instructions by also

I have used RODBC to get the database i can view the tables in RGUI-2.4.1 how can i query the records in R> i tried with sqlQuery need some help JJ -- Lecturer J. Joshua Thomas KDU College Penang Campus Research Student, University Sains Malaysia -- Lecturer J. Joshua Thomas KDU College Penang Campus Research Student, University Sains Malaysia [[alternative HTML version deleted]]

Hello LLD developers! Lld is claimed to be compatible with the existing linker options. However, there is a discrepancy in how the -Bstatic switch (disable linking against shared libs) is treated by lld and GNU ld. According to the GNU ld docs, the switch affects library searching for -l options *which follow it*. This means -Bstatic can be used multiple times in the command line to disable

Hi Simon, Thank you for the info. Do you know if there are any plans to add -Bdynamic support and make -Bstatic/-Bdynamic compatible with GNU ld? I am giving lld a try building the Boost libraries and this is a real show stopper. Boost.Build passes both -Bstatic and -Bdynamic to the linker which makes lld think the output file is static, so it totally ignores shared libraries. This breaks

On 3/30/2017 9:03 PM, Reid Kleckner via llvm-dev wrote: > On Thu, Mar 30, 2017 at 5:57 PM, Edward Diener via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Actually just doing: > > clang++ -c t.cpp -o t.o --target=x86_64-windows-msvc -fmsc-version=1900 > clang++ t.o -o t.exe --target=x86_64-windows-msvc

While considering statically linking against libc++ (and other runtime libraries from LLVM), I rebuilt LLVM 4.0 with -DBUILD_SHARED_LIBS=OFF. There are still some .so's in llvm/lib, and only one of them seems to exist exclusively as a DSO (libLTO). There's also livLLVMLTO.a, but I doubt LTO is used after linking a binary so this just looks odd to an uninformed LLVM outside and not

On 3/30/2017 7:59 PM, Reid Kleckner via llvm-dev wrote: > On Thu, Mar 30, 2017 at 6:08 AM, Edward Diener via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Are you saying that once lld is built with mingw-64/gcc on Windows > it is impossible to tell it to handle PE/COFF files when invoking it > from clang++ using the

I have a bit of a problem with installation. I installed wxX11 in my linux box. I compiled the demos and all the demos, save dbbrowse, work. I think I have a functional wx. Now I''m trying to install wxRuby from source, since I have a 64 bit machine. I only have permission to my home directory so my installation is : /usr/people/stevenq/Applications/wxX11/

Hi All, Unless I missed something, it seems to me that metadata can not be carried by target specific intrinsics when moving in and out of selectionDAG. The attached patch add support for this. The only point worth noticing is about the selectionDAGBuilder part : the regular getValue() path is not used, as its intended --- and enforced --- usage is for 'real' values, with a register

I want to create a vector version sqrt as the following. Value *Approx::CreateFSqrt(IRBuilder<> &builder, Value *v, const char* Name) { Type *tys[] = {v->getType()}; Module* M = currF->getParent(); Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd); CallInst *CI = builder.CreateCall(sqrtv, v, Name); return CI; } Here is Value *v is <2 x

Hello, I'm currently looking into integrating the patchpoint and stackmap intrinsics into my pet project. In their current implementation (3.4 and trunk) the code to emit the additional section is only executed on Darwin. This is however quickly fixed: Add a ".llvm_stackmaps"-Section for ELF in MCObjectFileInfo and execute StackMaps::serializeToStackMapSection in X86AsmPrinter in

Thanks, Shahid. It is fixed now. On Fri, Apr 17, 2015 at 8:50 PM, Shahid, Asghar-ahmad < Asghar-ahmad.Shahid at amd.com> wrote: > Hi zhi, > > > > You have to also pass the value type to getDecalaration() API such as > > > > Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd, > v->getType()); > > > > Regards, > >

Is there a reason why? IE is it hard to maintain, slow, or are you just worried it will break? or something else? (I'm not opposed in any way, literally just want to understand the motivation) On Wed, Sep 20, 2017 at 12:20 PM, Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics > that have

We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics that have been replaced with native IR over the years. Has enough time and/or versions passed that we can begin phasing out some of this code? As I'm writing these we don't seem to have tests for a lot of the older upgrades. We've done better at this in the last few years. 3.1 added upgrade for: