similar to: [LLVMdev] why llvm does not have uadd, iadd node

So if the overflow happens for either one of the case, the return value will be implementation dependent? best kevin On Feb 17, 2015, at 2:01 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Kevin, > > On 17 February 2015 at 10:41, kewuzhang <kewu.zhang at amd.com> wrote: >> I just noticed that the LLVM has some node for signed/unsigned type( like udiv,

Hi Guys, I see an intrinsic function call like this "call float @ir.sample_complex.f32(float a, int bitcast (i16 337203 to i32) , i32 1, <2 x float> %62, float %61) “, Then I got trouble to process the third operand "int bitcast (i16 337203 to i32)”, the second operand I got is “constant 337203”. I think something is messed up, but the getOperand(i) is llvm core function.

Tks Tom, That is my confusing part. How can I make it to "access memory” so it will HasChain? Is there any flag set like in typeProfile, Node, instructions? myLoad, mayStore, SDNPHasChain? -kevin On Jul 18, 2014, at 4:26 PM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Jul 18, 2014 at 04:15:45PM -0400, kewuzhang wrote: >> sure! >> >> class

On Jul 31, 2014, at 7:23 PM, Tom Stellard <tom at stellard.net> wrote: > On Thu, Jul 31, 2014 at 06:41:06PM -0400, kewuzhang wrote: >> Hi All, >> >> Is it possible to initialize(set up) register attributes when we define an instruction? >> >> like >> >> if a register is defined like this: >> >> " class

Hi guys, In X86ISelLowering.cpp I saw” ... case Intrinsic::x86_rdrand_16: case Intrinsic::x86_rdrand_32: …. case Intrinsic::x86_avx512_gather_qpd_512: case Intrinsic::x86_avx512_gather_qps_512: .. “ those intrinsics are handled by “LowerINTRINSIC_W_CHAIN”. How the “INTRINSIC_W_CHAIN” opCode is set instead of “INTRINSIC_WO_CHAIN”? tks Kevin -------------- next part -------------- An

Hi Pete, > Or do you mean that the result of an add may not even be defined? In that case would reading it be considered UB in the case where the overflow bit was set? Yeah, this is the case I'm worried about: that for example sadd.with.overflow(INT_MAX, 1) might be designed to return { poison, true } instead of giving a useful result in the first element of the struct. John

Dear there, I have a target which is supporting the 32 bit operations natively. Right now,I want to make it support the 16 bits operations as well. My initial thought is: (1) I can adding something like “ CCIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. but looks it is not

CGP also relies on the add being a simple two's complement add, since it will transform define void @test1(i64 %a, i64 %b, i64* %res_i64, i1* %res_i1) { entry: %add = add i64 %b, %a %cmp = icmp ult i64 %add, %a store i1 %cmp, i1* %res_i1 store i64 %add, i64* %res_i64 ret void } to define void @test1(i64 %a, i64 %b, i64* %res_i64, i1* %res_i1) { entry: %uadd.overflow = call

Hi Guys, I am trying to promote half to float for my intrinsic math operations, following class and pattern are defined. " class S_HF__HF< string asmstr> : Intrinsic <[llvm_float_ty ], [llvm_float_ty ], [IntrNoMem], !strconcat(asmstr, "_f16")>; def :Pat<( f16 (int_my_math_f16 f16:$src)), (F2Hsr (FEXTsr f16:$src) )>; “ where FEXTsr is

Hi Guys, In LLVM codegen, a typical binary operation instruction is defined something like below: " def _rr: NVPTXInst<(outs Int1Regs:$dst), (ins Int1Regs:$a, Int1Regs:$b), "xor.pred \t$dst, $a, $b;", [(set Int1Regs:$dst, (OpNode Int1Regs:$a, Int1Regs:$b))]>; “ which takes two inputs and write the result to the $dst register. Then how to define a binary

Hi guys, I am working on an intrinsic function, which will write to a pointer argument. So I am lowering it and think I need to catch it in lowerINTRINSIC_W_CHAIN, but somehow it always fall into INTRINSIC_WO_CHAIN category. I put [IntrReadwriteArgMem] into my Intrinsic class definition, it did not help. tried put [SDNPHasChain] into intrinsic class definition, cause errors” Element type

Hi All, In XCore backend, I saw “ …... EVT VT = Op.getValueType(); SDValue Data = DAG.getNode(XCoreISD::CRC8, DL, DAG.getVTList(VT, VT), Op.getOperand(1), Op.getOperand(2) , Op.getOperand(3)); SDValue Crc(Data.getNode(), 1); SDValue Results[] = { Crc, Data }; return DAG.getMergeValues(Results, 2, DL); “ which is used to lower an

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

Hi Guys, I noticed that the operation actions( promote/expand/custom) are set per operation basis. Wondering if we can set it up globally? For example, I have native supported 32 bits registers, to handle 8 bits value operations, I want to do promote. and to support 64 bit operations, I want to expand. If I can set up the operation actions for the same type globally, then I can avoid to

Hi, I’d like to propose to extend LLVM IR intrinsics set, adding new ones for safe-division. There are intrinsics for detecting overflow errors, like sadd.with.overflow, and the intrinsics I’m proposing will augment this set. The new intrinsics will return a structure with two elements according to the following rules: safe.[us]div(x,0) = safe.[us]rem(x,0) = {0, 1} safe.sdiv(min<T>, -1) =

>> In other words, abandoning overflow detection makes the >> duplication of types redundant, while requiring it would be a >> great burden on CPUs that don't have overflow exception hardware. > >Yes, you're right. This has been a desired change for quite some time >now. Unfortunately, its a huge impact to nearly every part of LLVM. We >will

Hi everyone! The fptoui/fptosi instructions are currently specified to return a poison value if the rounded-towards-zero floating point number cannot be represented by the target integer type. The motivation for this behavior is that overflowing float to int casts in C are undefined behavior. However, many newer languages prefer to have a float to integer cast that is well-defined for all input

Hi All, The following code : void hexagon2( int *a, int *res ) { int i = 100; while ( i-- ) { *res++ = *a++; } } gets compiled as a sub-optimal Software loop on LLVM 9.0 instead of a Hardware loop, whereas it was compiled as a Hardware Loop in LLVM 7.0. This is the final assembly code generated by LLVM 9.0 : .text .file "main.c" .globl hexagon2 // --

Hi Tom, Matt, I'm running into strange issues with the cos test (piglit generated_tests/cl/builtin/math/builtin-float-cos-1.0.generated.c) I have been seeing random failures (incorrect results) for some time and tried to investigate. the weird part is that the failures are not 100% reproducible, sometimes the tests pass, or partly pass (it's usually float8 and float16 subtests that

Introduction: We would like to add new keyword to 'sdiv'\'udiv' instructions i.e. 'no-overflow'. This is the updated solution devised in the discussion: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118257.html The proposed keywords: "nof" stands for 'no-overflow' Syntax: <result> = sdiv nof <ty> <op1>,