similar to: [LLVMdev] [compiler-rt] cmake fails to configure for AArh64

Displaying 20 results from an estimated 7000 matches similar to: "[LLVMdev] [compiler-rt] cmake fails to configure for AArh64"

2014 Sep 10
3
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
Hi Oleg, On 01/09/14 18:46, Oleg Ranevskyy wrote: > Hi Duncan, > > I looked through the IEEE standard and here is what I found: > > *6.2 Operations with NaNs* > /"For an operation with quiet NaN inputs, other than maximum and minimum > operations, if a floating-point result is to be delivered the result shall be a > quiet NaN which should be one of the input
2014 Sep 22
2
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
Hi Duncan, On 17.09.2014 21:10, Duncan Sands wrote: > Hi Oleg, > > On 17/09/14 18:45, Oleg Ranevskyy wrote: >> Hi, >> >> Thank you for all your helpful comments. >> >> To sum up, below is the list of correct folding examples for fadd: >> (1) fadd %x, -0.0 -> %x >> (2) fadd undef, undef -> undef
2014 Sep 17
3
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
Hi, Thank you for all your helpful comments. To sum up, below is the list of correct folding examples for fadd: (1) fadd %x, -0.0 -> %x (2) fadd undef, undef -> undef (3) fadd %x, undef -> NaN (undef is a NaN which is propagated) Looking through the code I found the "NoNaNs" flag accessed through an instance of
2014 Sep 16
2
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
As far as I know, LLVM does not try very hard to guarantee constant folded NaN payloads that match exactly what the target would generate. —Owen > On Sep 16, 2014, at 10:30 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote: > > Hi Duncan, > > I reread everything we've discussed so far and would like to pay closer attention to the the ARM's FPSCR register
2017 Jan 09
2
Removed a call to EmitXRayTable() from ARMAsmPrinter
Hi Renato, As far as I understand, such issues should be caught by the tests in compiler-rt/test/xray/TestCases/Linux. I found the following lines in compiler-rt/test/xray/lit.cfg that seem to disable the tests for non-64-bit targets: if config.host_os not in ['Linux'] or config.host_arch.find('64') == -1: config.unsupported = True @Serge: You will need to change this
2014 Sep 01
2
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
Hi Oleg, On 01/09/14 15:42, Oleg Ranevskyy wrote: > Hi, > > Thank you for your comment, Owen. > My LLVM expertise is certainly not enough to make such decisions yet. > Duncan, do you have any comments on this or do you know anyone else who can > decide about preserving NaN payloads? my take is that the first thing to do is to see what the IEEE standard says about NaNs.
2014 Sep 26
2
[LLVMdev] [lld] A primitive program linked by lld core dumps
Hi, I've encountered a newly introduced bug in lld today. I am building my program with clang and lld on an X86-64 Ubuntu Linux machine. Command line: clang main.c The compiled program invokes the "main" function multiple times until it closes with a segmentation fault. This affects even the most primitive programs like "int main() { return 0; }". The problem
2014 Sep 17
2
[LLVMdev] [lld] -Bstatic / -Bdynamic switches handling
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
2014 Aug 29
2
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
LLVM does not (today) try to preserve rounding mode or sNaNs. The only remaining question is whether we should be trying to preserve NaN payloads. —Owen On Aug 29, 2014, at 5:39 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote: > Hi, > > So, the result of "fadd x, -0.0" might have a bit pattern different from the one of "x" depending on the value of
2015 May 21
2
[LLVMdev] Driver::GetProgramPath is unable to find programs with file extension in name
Hello, We are having a problem with linker lookup on Windows. When the driver tries to locate a program by its name, e.g. a linker, it scans the paths provided by the toolchain using ScanDirForExecutable and then, if fails, uses llvm::sys::findProgramByName, which on Windows searches the CWD and system path. ScanDirForExecutable disregards file extensions, so search in the toolchain-provided
2015 Sep 18
5
Fwd: Skipping names of temporary symbols increased size of ARM binaries.
CC llvm-dev ---------- Forwarded message ---------- Hello Duncan The size of ARM binaries created by clang has increased after r236642. Would you be able to find some time to look at my findings and share your thoughts about the problem, please? r236642 prevents emitting of temp label names into object files to save memory. This is fine, the label names do not appear in the resulting binaries.
2014 Sep 17
2
[LLVMdev] [lld] -Bstatic / -Bdynamic switches handling
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
2015 Jun 24
2
[LLVMdev] No location info for artificial arguments: cannot step into class methods
Hi David, I got a problem related to the change made in r188651 - not including file/line info for artificial arguments like "this" and "self". Would you be able to take a look at it, please? I am compiling the code for ARM linux with fast ISel disabled: -mllvm -fast-isel=0. The problem is that it's not possible to step intothe constructor, destructor or a method of a
2016 Apr 23
2
[IndVarSimplify] Narrow IV's are not eliminated resulting in inefficient code
Hi Sanjoy, Thank you for looking into this! Yes, your patch does fix my larger test case too. My algorithm gets double performance improvement with the patch, as the loop now has a smaller instruction set and succeeds to unroll w/o any extra #pragma's. I also ran the LLVM tests against the patch. There are 6 new failures: Analysis/LoopAccessAnalysis/number-of-memchecks.ll
2017 Jan 10
2
Removed a call to EmitXRayTable() from ARMAsmPrinter
Why there are no tests that would break in this case? On Mon, Jan 9, 2017 at 8:32 PM, Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Oops -- sorry about that, this is definitely unintended. Adding in Martin who made the change. > > I'm happy to review changes to fix this, or if you don't get to it first I can drive by that part of the code and try
2017 Jan 25
2
Unstable XRay test on ARM
+Dean Michael Berris <dberris at google.com> On Wed, Jan 25, 2017 at 7:01 AM Oleg Ranevskyy via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Renato, Dean, Serge, > > Just looked into the code and wanted to share some thoughts. > > This might be a compare_exchange_weak spurious failure. ARM is a weakly > ordered CPU, but I am not sure whether spurious failures
2014 Aug 26
2
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
Hi Duncan, Thank you for your comment to the bug 16257. I am new to LLVM, so not all the aspects of LLVM's /"undef"/ seem clear to me yet. I read and understood the examples from the LLVM documentation: http://llvm.org/docs/LangRef.html#undefined-values However, those examples do not cover all of the possible contexts where /"undef"/ can appear. E.g., I can't
2014 Aug 27
3
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
Duncan, > Hi Oleg, > >> >> /This is either a mistake, or a decision that in LLVM IR snans >> are always >> considered to be signalling. / >> Yes, this seems to be an agreement to treat "undef" as a SNaN for >> "fdiv". > > "undef" is whatever bit pattern you want it to be, i.e. the compiler > can assume it is any
2017 Jan 09
2
Removed a call to EmitXRayTable() from ARMAsmPrinter
Sharing with the mailing list... Please, see below. On 9 January 2017 at 23:45, Serge Rogatch <serge.rogatch at gmail.com> wrote: > Hi Dean, > > I have seen that you removed the following code from ARMAsmPrinter.cpp in > revision 290858: > // Emit the XRay table for this function. > EmitXRayTable(); > > Was this done by mistake or on purpose? > > Without
2014 Aug 27
2
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
Hi Duncan, Thank you a lot for your time to provide that great and informative explanation. Now the "undef" logic makes much more sense for me. >> /You are wrong to say that "div undef, %X" is folded to "undef" by InstructionSimplify, it is folded to zero./ My mistake. I meant to say "*f****div* undef, %X" is folded to "undef" (not