similar to: [LLVMdev] optimization in presence of floating point

Displaying 20 results from an estimated 9000 matches similar to: "[LLVMdev] optimization in presence of floating point"

2013 Apr 18
0
[LLVMdev] optimization in presence of floating point
----- Original Message ----- > From: "reed kotler" <rkotler at mips.com> > To: LLVMdev at cs.uiuc.edu > Sent: Wednesday, April 17, 2013 8:32:23 PM > Subject: [LLVMdev] optimization in presence of floating point > > an interesting problem occurs if you do interval arithmetic. > > void foo() { > float XL, XU, Y, Z; > > .... >
2013 Apr 18
1
[LLVMdev] optimization in presence of floating point
For reordering issues, it would be useful for llvm ir to provide various ways to control reordering. for example, a wrapper that indicates that other operations cannot be moved inside the wrapper. or a wrapper that indicates that the IR in it must be processed canonically. I think GCC may already have some of this but I'm not sure. On 04/17/2013 08:59 PM, Hal Finkel wrote: > -----
2020 Mar 05
3
Should rint and nearbyint be always constrained?
+cfe-dev as the discussion is now biased toward C standard. I'm not sure what problem you see here. In default mode, i.e. > when there is no "#pragma STDC FENV_ACCESS on" in effect, > then the compiler can always assume that the default rounding > mode is in effect. Well, if #pragma STDC FENV_ACCESS on is not in effect, that means > that the user has promised that at
2012 Sep 21
2
[LLVMdev] mips16 puzzle
Trying to think of a clever way to do something.... On Mips 16, the SP (stack pointer) is not a directly accessible register in most instructions. There is a way to move to and from mips 16 registers (subset of mips32) and mips32 registers. For the load/store word instructions, there are forms which implicitly take SP. However, for store/load byte and store/load halfword, there is no such
2018 May 23
2
Update on strict FP status
On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > Hi Ulrich, > > I am interested in knowing if the current proposals also take into > account the FP_CONTRACT pragma We should already do this (we turn relevant operations into the @llvm.fmuladd. when FP_CONTRACT is set to on during IR generation). > and the ability to implement options that imply a specific value for >
2018 May 23
0
Update on strict FP status
On Wed, May 23, 2018 at 12:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > > Hi Ulrich, > > I am interested in knowing if the current proposals also take into account > the FP_CONTRACT pragma > > > We should already do this (we turn relevant operations into the > @llvm.fmuladd. when FP_CONTRACT is
2012 Sep 21
2
[LLVMdev] mips16 puzzle
Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it. There are
2012 Sep 26
5
[LLVMdev] mips16 puzzle
We already divided out our classes as you did for ARM. The problem here is that we have a store/load byte/halfword to/from a Frame object. We know at that time that it's not going to be possible to store it using SP because there is only such instructions for store/load of a word. What we would want to do is to move SP into a Mips 16 register and then do a indexed load/store off of that
2012 Sep 21
0
[LLVMdev] mips16 puzzle
Reed, It's not clear to me that you need to do anything special here. If you define your MIPS16 register class as not containing SP, then any MIPS16 instructions that get selected and want to read from SP should get a COPY inserted from SP to a MIPS16 vreg. The coalescer should, ideally, get rid of extraneous copies for you. --Owen On Sep 20, 2012, at 10:48 PM, Reed Kotler <rkotler at
2012 Sep 26
0
[LLVMdev] mips16 puzzle
Ok. That's a somewhat different problem, then. Devil will be in the details of what you want to do. A few options. First is to always have a standard frame pointer register available and reference off of that. Caveat: dynamic stack realignment and vararrays muck with that more than a bit. Second is what gcc is doing and reserve a register just for this in addition to the frame register.
2012 Sep 24
0
[LLVMdev] mips16 puzzle
On Sep 20, 2012, at 11:44 PM, Reed Kotler <rkotler at mips.com> wrote: > Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. > ARM has a similar problem. The InstrInfo
2020 Jan 29
2
Floating point semantic modes
Yes, you’re probably right about this. I was originally thinking of FENV_ACCESS as a fully strict mode of operation, but what you’re suggesting aligns with what Cameron suggested and even some of my own reasoning on other points. So, let me amend my previous proposal to say: STDC FENV_ACCESS {ON|OFF} Patch in progress. I think ON should force the following: except_behavior { strict }
2017 May 11
2
FENV_ACCESS and floating point LibFunc calls
Hi Andy, I’m interested to try out your patches… I understand the scope of FENV_ACCESS is relatively wide, however I’m still curious if you managed to figure out how to prevent the SelectionDAGLegalize::ExpandNode() FP_TO_UINT lowering of the FPToUI intrinsic from producing the predicate logic that incorrectly sets the floating point accrued exceptions due to unconditional execution of the
2020 Jan 07
3
Calling function from non-default floating-point environment
Hi all, Implementation of #pragma STDC FENV_ACCESS raises a problem: what to do if a function is called inside a region where FP environment differs from the default? If the function expects default FP mode it may work incorrectly in such case. The C2x standard draft ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf) states (7.6p4): Certain programming conventions support the intended
2012 Sep 29
1
[LLVMdev] mips16 puzzle
Turned out to be a rather simple fix. Just copied SP to a virtual register in the beginning of the function. Then added an extra operand to the DAGs with stack reference load/store, with the extra operand equal to this virtual register if the Parent of the address is a LOAD/STORE of an 8 or 16 bit quantity. It worked fine. When needed SP got copied to a mips 16 register and when the SP alias
2017 May 11
2
FENV_ACCESS and floating point LibFunc calls
Sounds like the select lowering issue is definitely separate from the FENV work. Is there a bug report with a C or IR example? You want to generate compare and branch instead of a cmov for something like this? int foo(float x) { if (x < 42.0f) return x; return 12; } define i32 @foo(float %x) { %cmp = fcmp olt float %x, 4.200000e+01 %conv = fptosi float %x to i32 %ret = select
2017 May 11
3
FENV_ACCESS and floating point LibFunc calls
Thanks, Andy. I'm not sure how to solve that or my case given the DAG's basic-block limit. Probably CodeGenPrepare or SelectionDAGBuilder...or we wait until after isel and try to split it up in a machine instruction pass. I filed my example here: https://bugs.llvm.org/show_bug.cgi?id=33013 Feel free to comment there and/or open a new bug for the FP_TO_UINT case. On Thu, May 11, 2017 at
2020 Jan 27
11
Floating point semantic modes
Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set
2017 May 10
2
FENV_ACCESS and floating point LibFunc calls
Hi all, Background I've been working on adding the necessary support to LLVM for clang to be able to support the STDC FENV_ACCESS pragma, which basically allows users to modify rounding mode at runtime and depend on the value of floating-point status flags or to unmask floating point exceptions without unexpected side effects. I've committed an initial patch (r293226) that adds
2020 Jan 09
2
[cfe-dev] Calling function from non-default floating-point environment
On 7 Jan 2020, at 14:00, Kevin Neal via cfe-dev wrote: > Right here it says that dealing with non-default modes is the job of > the program or programmer: “The responsibilities associated with > accessing the floating-point environment fall on the programmer or > program that does so explicitly.” It doesn’t say compiler. It also > hedges with words like “certain ...