similar to: [LLVMdev] More careful treatment of floating point exceptions

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 its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still

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

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

Hello Sergey, thanks for the suggestion. The name of the pass is not what triggers the assertion. The test case I attached 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,

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

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

Just got clang from head and getting: ExprConstant.cpp: In function Obool TryEvaluateBuiltinNaN(clang::ASTContext&, clang::QualType, const clang::Expr*, bool, llvm::APFloat&)¹: ExprConstant.cpp:1578: error: no matching function for call to Ollvm::StringRef::getAsInteger(int, llvm::APInt&)¹ /home/neale/LLVM/llvm/include/llvm/ADT/StringRef.h:269: note: candidates are: bool

Hi Chandler, This scheme has significant advantages over what was being pursued, but one question (or two)... Under the proposed system, how would you represent the necessary dependency edges between the fp intrinsics and function calls? How is the state 'returned' to the caller? [I was thinking that our new operand bundles could help for the inputs, but the outputs? Plus what about the

I’m tying to run a rust application on armv4 architecture (arm720tdmi). Rust is using llvm to generate native code. Some programs are running well on the target but for more complex applications I receive a Illegal instruction : gdb disassembling the core dump file gives : 0x401e41dc <+0>: push {r11, lr} 0x401e41e0 <+4>: mov r11, sp 0x401e41e4 <+8>: sub sp, sp, #8

FWIW, +1 from me. Just one request on the implementation though. However we model these intrinsics and their properties (metadata, constants, etc), can we please abstract away those details the same way we have MemCpyInst which just wraps an IntrinsicInst? I think this would be very beneficial if we ever need to add more state, or change something about the underlying implementation, and not

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Chandler Carruth" <chandlerc at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, February 5, 2016 4:36:54 PM > Subject: Re: [llvm-dev] [RFC] FP Environment and Rounding mode

On 8 August 2013 19:18, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I am hoping that this proposal will generate a lot of feedback, and there > are many different topics to discuss. When replying to this email, please > change the subject header to something more specific, but keep the > [global-isel] tag. Sorry, looks like I cannot edit the subject line on gmail. 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 >

Hi, Sorry for the late report but I've only just found these issues. Llvm.org isn't working for me at the moment but I'll file tickets once it is. The issues are: 1. Almabench has some significant numerical differences and fails the reference check for some configs. I'm investigating this one at the moment but early indications are that it's a similar (but different)

Hi LLVM developers, I am implementing Loong Language[1] using Clang FrontEnd and LLVM MiddleEnd. I add `wire`[2] Builtin Type, and clang is able to parse very small testcase fulladder[3] but failed to work for 10+K loc RISCV E203 project[4]: Loongson clang version 7.0.0 (git at github.com:Loong-Language/loong-clang.git 8f7e826f27abbe12ea08d9563490298c38d3adc1) (git at

R is having trouble finding some of the things it needs to compile. In particular, I'm getting messages saying that it can't find things it wants in -lblas, -ldxml, -ldnet, and -ldnet_stub. It also can't find dl.h, ieeefp.h, and ieee754.h. I can't figure out whether these things are included with R somewhere and I need to tell it where to look, or they're not included and I