search for: fpround

...parameters. Optional parameter tuples would be very useful for constrained fp intrinsics and vector predication. Some examples: ; Default fpenv fadd (isomorphic to the fadd instruction) %z = call double @llvm.fadd(%a, %b) ; Constrained fp add %x = call double @llvm.fadd(%a, %b) fpenv(metadata !fpround.tonearest, metadata !fpexcept.strict) ; Constrained fp add with vector predication (https://reviews.llvm.org/D57504) %x = call <256 x double> @llvm.fadd(%a, %b) mask(<256 x i1> %mask), evl(i32 %evl), fpenv(metadata !fpround.tozero, metadata !fpexcept.strict) For constrained fp and VP...

...ed by the intrinsic seems vaguely wrong. A typical call to a current intrinsic looks like this: %sum = call double @llvm.experimental.constrained.fadd(double %x, double %y, Metadata "fpround.dynamic", Metadata "fpexcept.strict") The idea I am pursuing in my patch is to replace these metadata arguments with optional operand bundles, "fpround" and "fpexcept". If the operand bundles are present, the...

I am trying to upgrade to the LLVM v4.0 branch, but I am seeing failures in my TableGen descriptions for conversion from FP32 to FP16 (scalar and vector). The patterns I have are along the lines of: [(set (f16 RF16:$dst), (fround (f32 RF32:$src)))] or: [(set (v2f16 VF16:$dst), (fround (v2f32 VF32:$src)))] and these now produce the errors: error: In CONV_f32_f16: Type inference

...esented by the intrinsic seems vaguely wrong. A typical call to a current intrinsic looks like this: %sum = call double @llvm.experimental.constrained.fadd(double %x, double %y, Metadata “fpround.dynamic”, Metadata “fpexcept.strict”) The idea I am pursuing in my patch is to replace these metadata arguments with optional operand bundles, “fpround” and “fpexcept”. If the operand bundles are present, they would mean what the arguments cur...

...assumptions by default. The state where the assumptions are not made is accomplished through the use of constrained intrinsics. However, we do not wish to completely eliminate optimizations in all cases, so we want a way to communicate to the optimizer what it can assume. That is the purpose of the fpround and fpexcept arguments. These are not intended to control the rounding mode or exception reporting. They only tell the compiler what it can assume. Understanding this, front ends can control these in any way they see fit. For instance, the front end might have a global setting the changes the roun...

...s a register of class "Pair64". Is there a way to define it such that the register class is defined at runtime when we know if it should be a 64-bit register class? def FD2S_rr: RRX<0b00110,0,0,0, (outs Core32:$a), (ins Pair64:$b), "FD2S\t$a,$b"),[(set f32:$a, (fpround f64:$b))]>; Example register classes: def Core32: RegisterClass<"XYZ", [i32,f32], 32, (add R0,R1,R2,R3,... def Pair64: RegisterClass<"XYZ", [i64,f64], 64,... (add R0R1, R2R3,... def WideCore : RegisterClass<"XYZ", [i64,f64], 64...

...s that do not. The FP exceptions are assumed to be ignored. llvm.rint (delete, or identical semantics to llvm.nearbyint) llvm.experimental.constrained.nearbyint::semantics This function returns the same value as one of the IEEE 754-2019 roundToIntegral operations. If the roundingMode argument is fpround.dynamic, the behavior corresponds to whichever of the roundToIntegral operations matches the dynamic rounding mode when the operation is executed. The optimizer may not assume any rounding mode in this case, and backends must encode the operation in a way that uses the dynamic rounding mode. Otherw...

...taught to handle the intrinsics correctly then it isn’t limited by > anything other than the semantics of the constraints. Once we’ve > updated an optimization pass, it will be able to do everything with a > constrained intrinsic that has the “relaxed” settings > (“fpexcept.ignore” and “fpround.tonearest”) that it would be able to > do with the regular operation. The way I understood it, the constraint intrinsics are not the only problem but the regular ones can be. That is, optimizations will move around/combine/replace/... regular floating operations in the presence of constraint in...

...efining what happens > when dynamic and "assumed" rounding mode don't match (see above) also > addresses this problem. Then the operations can be described like this: > > > If a rounding mode is assumed [RNE for non-constrained intrinsic or > roundingMode argument != fpround.dynamic] and the current dynamic rounding > mode differs from the assumed rounding mode, [pick one: behavior is > undefined / result is poison / ...]. Otherwise, X operation is performed > with the current dynamic rounding mode [which equals the statically assumed > rounding mode if thi...

...ynamic and "assumed" rounding mode don't match (see above) also >>> addresses this problem. Then the operations can be described like this: >>> >>> > If a rounding mode is assumed [RNE for non-constrained intrinsic or >>> roundingMode argument != fpround.dynamic] and the current dynamic rounding >>> mode differs from the assumed rounding mode, [pick one: behavior is >>> undefined / result is poison / ...]. Otherwise, X operation is performed >>> with the current dynamic rounding mode [which equals the statically assumed &...

> > I'm not sure why this is an issue. Yes, these two intrinsics depend > on the current rounding mode according to the C standard, and yes, > LLVM in default mode assumes that the current rounding mode is the > default rounding mode. But the same holds true for many other > intrinsics and even the arithmetic IR operations like add. Any other intrinsic, like `floor`,

Hi all, This proposal is aimed at support of floating point environment, in which some properties like rounding mode or exception behavior differ from those used by default. This include in particular support of 'pragma STDC FENV_ACCESS', 'pragma STDC FENV_ROUND' as well as some other related facilities. Problem On many processors use of non-default floating mode requires