search for: ranevskyy

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...

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 >>...

...supported = True @Serge: You will need to change this condition to enable the tests for ARM. Oleg ________________________________________ From: Renato Golin <renato.golin at linaro.org> Sent: Monday, January 9, 2017 11:50 PM To: Serge Rogatch Cc: Dean Michael Berris; LLVM Developers; Oleg Ranevskyy Subject: Re: [llvm-dev] Removed a call to EmitXRayTable() from ARMAsmPrinter On 9 January 2017 at 20:47, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Without this call, xray_instr_map gets empty in the executable, so that >> XRay doesn't patch anything. W...

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 mentioned by Stephen. > It's really possible on ARM systems that floating point operations on...

...generate. > > I'm with Owen here. Unless ARM people object, I think it is > reasonable to say that at the LLVM IR level we may assume that the > IEEE rules are followed. > > Ciao, Duncan. > >> >> —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 mentioned by Stephen. >>> It's...

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 i...

...-Bdynamic is > not recognized at all. -Bstatic and -Bshareable are aliases for > -static and -shared options respectively. The linker uses the last > option specified in a command line just to select type of output file. > > ​Simon​ > > On Wed, Sep 17, 2014 at 4:30 PM, Oleg Ranevskyy > <llvm.mail.list at gmail.com <mailto:llvm.mail.list at gmail.com>> wrote: > > 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 linki...

...;t get to it first I can drive by that part of the code and try and fix it myself. I unfortunately don't have easy access to arm machines so it is a little hard for me to try and fix these things proactively (or not catch them in the first place). :( > >> On 10 Jan 2017, at 08:32, Oleg Ranevskyy via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 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 disabl...

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 "x" and the target. > If I get it right, the result does not necessarily compare equal t...

Hi, I am trying to cross compile LLVM/clang for AArch64 on an X86_64 Linux host using aarch64-linux-gnu-gcc / aarch64-linux-gnu-g++. Important is that I have compiler-rt checked out to the llvm/projects folder. "cmake -G 'Unix Makefiles' ..." is used to configure the build folder. The problem: cmake fails to configure. The reason: cmake passes the -m64 option to

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

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.

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

+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 failure...

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 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

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

...Thanks! > > Ciao, Duncan. > >> >> Would you be able to elaborate on this please? >> Thank you! >> >> Kind regards, >> Oleg >> >> On 26.08.2014 15:47, Duncan Sands wrote: >>> Hi Oleg, >>> >>> On 26/08/14 21:20, Oleg Ranevskyy wrote: >>>> 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...

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

...ndef" isn't zero, it's impossible to get an arbitrary bit pattern anyway. The result will always be divisible by 5. Would you be able to elaborate on this please? Thank you! Kind regards, Oleg On 26.08.2014 15:47, Duncan Sands wrote: > Hi Oleg, > > On 26/08/14 21:20, Oleg Ranevskyy wrote: >> 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: >> ht...