search for: fp_to_uint

...writing more patterns, but I am still hitting another roadblock. I attempted what you suggested and it fixed that issue, but then it started giving a warning that there is an unknown node in the resulting pattern. // unsigned int: f64->i32 ==> f64->f32 + f32->i32 def : Pat<(i32 (fp_to_uint (f64 GPR:$src0))), (i32 (fp_to_uint (f32 (dp_to_fp (f64 GPR:$src0)))))>; 1>Building AMDil.td instruction selector implementation with tblgen 1>(fp_to_uint:i32 (dp_to_fp:f32 GPR:f64:$src0)) 1>f:\hq\main\sw\appeng\tools\hpc\opencl\llvm\win32\AMDIL\..\bin\Win32\De bug\TableGe...

...ut I am still hitting another roadblock. I attempted what you > suggested and it fixed that issue, but then it started giving a > warning that there is an unknown node in the resulting pattern. > > // unsigned int: f64->i32 ==> f64->f32 + f32->i32 > def : Pat<(i32 (fp_to_uint (f64 GPR:$src0))), > (i32 (fp_to_uint (f32 (dp_to_fp (f64 GPR:$src0)))))>; > 1>Building AMDil.td instruction selector implementation with tblgen > 1>(fp_to_uint:i32 (dp_to_fp:f32 GPR:f64:$src0)) > 1>f:\hq\main\sw\appeng\tools\hpc\llvm\win32\AMDIL\..\bin\Win32\Debug...

...em itself is fairly simple. I need to go from 64bit floats to 32bit integers. As the backend doesn't support this natively but has a way of converting it, I'd prefer to get this working via tablegen. What I thought would work from the previous discussion is the following: def : Pat<(fp_to_uint (f64 GPR:$src0)), (fp_to_uint (f32 (dp_to_fp (f64 GPR:$src0))))>; Which when it runs across a 64bit float, it does a double to single conversion, and then calls the 32bit float to int routine. However, tablegen fails with the following error: 1>anonymous.2: (fp_to_uint:is...

...need to go from 64bit floats > to 32bit integers. As the backend doesn’t support this natively but > has a way of converting it, I’d prefer to get this working via > tablegen. > > What I thought would work from the previous discussion is the > following: > def : Pat<(fp_to_uint (f64 GPR:$src0)), > (fp_to_uint (f32 (dp_to_fp (f64 GPR:$src0))))>; > > Which when it runs across a 64bit float, it does a double to single > conversion, and then calls the 32bit float to int routine. > > However, tablegen fails with the following error: > 1&g...

...t;getOpcode(), Node->getOperand(0).getValueType()); This seems incorrect as SINT_TO_FP should be querying the convert action, and not the Operation action. i.e. it should be: case ISD::SINT_TO_FP: case ISD::UINT_TO_FP: case ISD::FP_TO_SINT: case ISD::FP_TO_UINT: Action = TLI.getConvertAction(Node->getValueType(), Node->getOperand(0).getValueType()); break; case ISD::EXTRACT_VECTOR_ELT: Action = TLI.getOperationAction(Node->getOpcode(), Node->getOperand(0).g...

...Node->getOperand(0).getValueType()); > > This seems incorrect as SINT_TO_FP should be querying the convert action, and not the Operation action. > > i.e. it should be: > case ISD::SINT_TO_FP: > case ISD::UINT_TO_FP: > case ISD::FP_TO_SINT: > case ISD::FP_TO_UINT: > Action = TLI.getConvertAction(Node->getValueType(), > Node->getOperand(0).getValueType()); > break; > case ISD::EXTRACT_VECTOR_ELT: > Action = TLI.getOperationAction(Node->getOpcode(), >...

...> recognized. This means that we need to treat those instructions as > having unmodelled side effects, so that they cannot be speculatively > executed. Also, we cannot schedule FP instructions across instructions Does this mean that the problems with the default expansion of ISD::FP_TO_UINT would be solved by the backend knowing that it should model traps? In D43515 the issue of what to do with STRICT_FP_TO_UINT is still unsolved. > that set (those bits in) the FP status register -- but the latter is > probably automatically done as long as those latter instructions are...

...d I would guess that your assessment regarding looping on input values is probably correct. I believe the code that actually creates most of the transformation you’re interested in here is in SelectionDAGLegalize::ExpandNode() in LegalizeDAG.cpp. The X86 backend sets a table entry indicating that FP_TO_UINT should be expanded for these value types, but the actual expansion is in target-independent code. This is what it looks like in the version I last fetched: case ISD::FP_TO_UINT: { SDValue True, False; EVT VT = Node->getOperand(0).getValueType(); EVT NVT = Node->getValueType(0...

...e 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 4:20 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Sanjay, > > > > The issue that Michael is talking about is that in SelectionDAGLegalize::ExpandNode() > we’re doing this: > > > > case ISD::FP_TO_UINT: { > >...

I assume the FP_TO_SINT, FP_TO_UINT use C "round to 0" convention? What about values out of range? I think C99 standard says these are undefined. Thanks, Dan

...I imagine that at some stage the OpenCL backend could migrate to the standard conversion instructions. This is what I propose: Add a "round" flag to FPToUIInst and FPToSIInst. The absence of this flag means truncation is needed whereas presence indicates rounding. The SelectionDAG for FP_TO_UINT and FP_TO_SINT are extended to add an immediate that indicates whether rounding is needed. To legalise a rounding FP_TO_UINT or FP_TO_SINT we use the technique described in [1] to convert the operation into an add/bitcast. Please let me know what you think. Thanks, -- Peter [1] http://www.d6.c...

...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 > ISD::FSUB node attached to the SELECT node. It’s a little above my head to > try to solve this issue with my curren...

...> quite sure what to do about that; if I can't come up with a better >> >> solution, I'll force the x86 backend to custom-lower that case. >> > > Attached is a more complete version, including the simplification of > LegalizeDAG and the fixes for UINT_TO_FP and FP_TO_UINT on x86. It > passes regression tests except for one failure due to a missing > implementation of legalization for EXTRACT_SUBVECTOR where both types > are legal. Should it be named something other than LegalizeVectors then, since it handles more than just vectors? Perhaps something like...

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 ISD::FSUB node attached to the SELECT node. It’s a little above my head to try to solve this issue with my current understanding of L...

...res type legalization.  I'm not > quite sure what to do about that; if I can't come up with a better > solution, I'll force the x86 backend to custom-lower that case. Attached is a more complete version, including the simplification of LegalizeDAG and the fixes for UINT_TO_FP and FP_TO_UINT on x86. It passes regression tests except for one failure due to a missing implementation of legalization for EXTRACT_SUBVECTOR where both types are legal. -Eli -------------- next part -------------- Index: test/CodeGen/X86/widen_cast-4.ll ========================================================...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...number of different people > (thanks everyone!), the current list of false-positives on `ninja > check-llvm` for the more stringent Gotcha A diagnostic is: > > LLVM :: Analysis/CostModel/X86/vselect-cost.ll > LLVM :: CodeGen/AMDGPU/GlobalISel/smrd.ll > LLVM :: CodeGen/AMDGPU/fp_to_uint.ll > LLVM :: CodeGen/AMDGPU/global-constant.ll > LLVM :: CodeGen/AMDGPU/merge-tbuffer.mir > LLVM :: CodeGen/AMDGPU/smrd.ll > LLVM :: CodeGen/AMDGPU/unhandled-loop-condition-assertion.ll > LLVM :: CodeGen/ARM/build-attributes.ll > LLVM :: CodeGen/ARM/float-helpers.s &gt...

...SD::SHL: + case ISD::SRA: + case ISD::SRL: + case ISD::ROTL: + case ISD::ROTR: + case ISD::CTTZ: + case ISD::CTLZ: + case ISD::CTPOP: + case ISD::SELECT: + case ISD::SELECT_CC: + case ISD::SINT_TO_FP: + case ISD::UINT_TO_FP: + case ISD::FP_TO_SINT: + case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTR...

I think we're going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the reason we're currently dropping that information). I'm out of my depth on this transition, but I think maybe we could