search for: dmitrouk

Out 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, 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 ] ...

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

...to the email 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 > >...

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

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 >

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

...ting point exceptions. 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 &quot...

...Use cases where 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 woul...

> 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

...to > compiler_rt, but I don't remember why. > I did dig into this further and it seems that they are, in fact, considered part of the RT-ABI :-(. Ive committed a simple conforming implementation in SVN r217322. > > Cheers, > > Jon > > > On 9/5/14, 12:10 PM, Sergey Dmitrouk wrote: > >> 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 >> &gt...

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:

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

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

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

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