search for: sdmitrouk

...of curiosity, how would you envision fast-math flags interacting with constant expressions? Off the top of my head, I can’t think of any flags that would be relevant if the expression can just be constant-folded away at full precision anyways. > On Nov 28, 2014, at 4:56 AM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com> wrote: > > Doesn't look like a bug, more like a limitation of constant expressions > as llvm::BinaryConstantExpr doesn't have FastMastFlags. > > -- > Sergey > > On Thu, Nov 27, 2014 at 03:39:20PM +0200, Sergey Dmitrouk wrote: >> Hi,...

...is a stripped-down version of a much more complicated pass (with a proper name) that originally caused the problem. Also, to be sure, I just tried to change the name of the pass to something more significant. It did not work. Cheers, Alberto On Sun, Aug 10, 2014 at 1:14 PM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com > wrote: > Hi Alberto, > > See [0], first argument of RegisterPass' constructor is argument name. > Try changing it to something more unique than "test", I guess it might > cause your issue. > > Regards, > Sergey > > [0]: http://ww...

Hi Renato, > > I'm trying to add pseudo 64-bit load and store instructions for AArch64, which > > should have latencies set to "1" while being otherwise exactly the same as > > normal load and store instructions. > > Can I ask why would you need that? This is the only way I found to stop Machine Instruction Scheduler from reordering load and store

Hi, I'd like to make code emitted by LLVM that includes floating point operations which raise FP exceptions behave closer to what is defined by IEEE754 standard. I'm not going to "fix everything", just incorrect behaviour I faced so far. Most of troubles regarding FP exceptions are caused by optimizations, so there should be a flag to disable/block them if one wants to get

Hi, I'm wondering why lib/AsmParser/LLParser handles fast-math flags in the following IR: ... %val = fmul nnan double 1.0, 1.0 ... but doesn't allow any flags if "fmul" is inside "phi": ... %val = phi double [ fmul (double 1.0, double 1.0), %cond.true ], [ fmul (double 1.0, double 1.0), %cond.false ] ...

.... Regards, Sergey On Fri, Sep 19, 2014 at 12:01:07PM -0700, Sanjay Patel wrote: > Hi Sergey - > > Does this solve part of the problem? > http://llvm.org/viewvc/llvm-project?view=revision&revision=215222 > On Fri, Sep 19, 2014 at 9:12 AM, Sergey Dmitrouk > <sdmitrouk at accesssoftek.com> wrote: > > Hi, > > I'd like to make code emitted by LLVM that includes floating point > operations which raise FP exceptions behave closer to what is defined by > IEEE754 standard.A I'm not going to "fix everything",...

...re we want to support a reasonable degree of conformance (e.g., still getting a division by zero exception), but without all the performance constrains of (2). This would be the default for normal clang invocations. > > —Owen > > > On Sep 19, 2014, at 12:59 PM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com> wrote: > > > > Hi Sanjay, > > > > Thanks, I saw this flag and it's definitely should be considered, but > > it appeared to me to be static characteristic of target platform. I'm > > not sure how appropriate it would be to change...

> Looks as though whomever implemented the call to __aeabi_idiv0 wanted > to be conservative for non EABI targets. How could it prevent him from providing default implementation of __aeabi_idiv0() for EABI targets? > AFAIK, gnueabi targets recognize all EABI functions, so that should > work well. Not sure I understand you, nothing in compiler-rt defines these functions, they are

Hello, I'm trying to add pseudo 64-bit load and store instructions for AArch64, which should have latencies set to "1" while being otherwise exactly the same as normal load and store instructions. Various assertions fire (even different ones for the same binary, maybe something is uninitialized) and I can't understand what's wrong. Related pieces added by me: to

Hi all, I am trying to create an out-of-tree LLVM project. I have written a Test project following the guide in [1] that triggers the problem. Pass body is in [2]. The CMakeLists.txt file for the "root" directory is in [3] The CMakeLists.txt file for the "pass" directory is in [4] When I run opt --load=libTest.so I trigger the following assertion: opt: CommandLine.cpp:134:

...> From: "Chandler Carruth" <chandlerc at gmail.com> > To: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org> > Cc: "Steve (Numerics) Canon" <scanon at apple.com>, "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>, "David Majnemer" > <david.majnemer at gmail.com>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Thursday, February 4, 2016 8:05:38 PM > Subject: Re: [RFC] FP Environment and Rounding mode handling in LLVM > > > First, thanks M...

Hi, There are several places in compiler-rt which refer to __aeabi_idiv0. For example, in lib/builtins/arm/udivsi3.S: #ifdef __ARM_EABI__ b __aeabi_idiv0 #else JMP(lr) #endif At the same time there is no definition of it. It looks as if it was done intentionally so that third-party could provide custom handler for division by zero. IMHO It's not very consistent and looks odd as

...m > >>>> To: "Mehdi Amini" < mehdi.amini at apple.com >, "llvm-dev" < >>>> llvm-dev at lists.llvm.org > >>>> Cc: "Steve (Numerics) Canon" < scanon at apple.com >, "Sergey >>>> Dmitrouk" < sdmitrouk at accesssoftek.com >, "David Majnemer" >>>> < david.majnemer at gmail.com >, "Hal Finkel" < hfinkel at anl.gov > >>>> Sent: Thursday, February 4, 2016 8:05:38 PM >>>> Subject: Re: [RFC] FP Environment and Rounding mode handling...

...; < chandlerc at gmail.com > > > To: "Mehdi Amini" < mehdi.amini at apple.com >, "llvm-dev" < > > llvm-dev at lists.llvm.org > > > Cc: "Steve (Numerics) Canon" < scanon at apple.com >, "Sergey > > Dmitrouk" < sdmitrouk at accesssoftek.com >, "David Majnemer" > > < david.majnemer at gmail.com >, "Hal Finkel" < hfinkel at anl.gov > > > Sent: Thursday, February 4, 2016 8:05:38 PM > > Subject: Re: [RFC] FP Environment and Rounding mode handling in > > LLVM &g...

Hi everyone, Sergey (CC’ed) worked on a series of patches to add support for floating-point environment and floating-point rounding modes in LLVM. This started *in 2014* and the patches after multiple rounds of review in the last months (involving amongst other Steve Canon, Hal Finkel, David Majnemer, and myself) are getting very close (IMO) to be in a state where we can land them. This is the

On Sat, Sep 06, 2014 at 04:48:20AM -0700, Renato Golin wrote: > I'm in favour for adding them ASAP, but we might need an ifdef to avoid > creating unnecessary (or conflicting) symbols for non-EABI targets. Sure, it makes sense. > A proper solution would be to have: > > LOCAL_LABEL(divby0): > #ifdef __ARM_EABI__ > b __aeabi_idiv0 > #else > mov r0, #0 >