similar to: [LLVMdev] get value of int greater than 64 bit?

So the problem here was trying to return MIN_VALUE zero extended, if I return sign extended than this issue is resolved; however, I still get an error with getSExtValue when trying to get the value of the const from Instruction: %mask166 = and i128 %lvar_ins176, -18446462598732840961 On Fri, Nov 16, 2012 at 3:17 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Eli, > > Thanks

Eli, Thanks for responding. Yes, I read the error message but it seems odd that it would be trying to use more than 64 bits. It compiles and executes in gcc on 32 bit arch just fine. I'll probably take your suggestion and file a bug with a reduced testcase. Thanks again, Ryan On Fri, Nov 16, 2012 at 3:10 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Nov 16, 2012

Hi, I was wondering how I can print out the result of some arithmetic on 128 bit integers. After having a look at the API , it seems it is possible to get the integer value from the "ConstantInt::getSextValue() " but the return value is only a int64_t. I wish to print it on the console output and printing as a string or decimal ( using C standard library printf ) My Question :

Hi, On 04/18/2016 05:28 PM, Vedant Kumar wrote: > This sounds like a bug to me. > > >> // If the last (struct) indices are constants and are equal, the other indices >> // might be also be dynamically equal, so the GEPs can alias. >> if (C1 && C2 && C1 == C2) >> return MayAlias; > > Does changing this condition fix the issue? E.g

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

I've been debugging some strange happenings over here and I put an assert in APInt to catch what I think is the source of the problem: int64_t getSExtValue() const { // An i1 -1 is unrepresentable. assert(BitWidth != 1 && "Signed i1 value is not representable!"); To me an i1 -1 makes no sense whatsoever. It is not representable in twos-complement form. It cannot

Hi all, I have the condition of an ICmpInst in a variable called condition obtained doing GenericValue condition = getOperandValue(&I, SF); Now I would like to understand if the comparison was true or false. Is it correct to use condition.IntVal.getSExtValue() and if the value is 0 consider the true and if the value is -1 consider the condition false? I'm not sure because I was expecting

Hi all, I want to match addition with 16bit integers. So I define a pattern fragment as follows: def simm16 : PatLeaf<(imm), [{ return isInt<16>(N->getSExtValue()); }]>; Now I am confused between (add R32:$dst, simm16:$im) and (add R32:$dst, (i32 simm16:$im)). Do both of them match the same pattern? Are they equivalent? If not what is the difference? I am also confused as to how

Hi Nick, Thanks, that seemed to work. Nick Lewycky wrote: > > ivtm wrote: >> I am processing the LLVM instructions and right now I am at the 'call' >> instruction. >> For now I just want to print the argument type. >> >> For example in the following: >> >> %0 = tail call i32 (...)* @__FFF (i32 8) nounwind; <i32> [#uses=1]

ivtm wrote: > I am processing the LLVM instructions and right now I am at the 'call' > instruction. > For now I just want to print the argument type. > > For example in the following: > > %0 = tail call i32 (...)* @__FFF (i32 8) nounwind; <i32> [#uses=1] > > I need to get access to 'i32' and '8' separately. > > I do: > >

Hi all In unittests/ADT/APIntTest.cpp I came across this test: // XFAIL this test on FreeBSD where the system gcc-4.2.1 seems to miscompile it. #if defined(__llvm__) || !defined(__FreeBSD__) TEST(APIntTest, i33_Count) { APInt i33minus2(33, static_cast<uint64_t>(-2), true); EXPECT_EQ(0u, i33minus2.countLeadingZeros()); EXPECT_EQ(32u, i33minus2.countLeadingOnes()); EXPECT_EQ(33u,

All, Just in case you're not on the llvm-commits list, the classes ConstantSInt and ConstantUInt have been removed from the LLVM C++ IR. This affects only the CVS HEAD. A patch to llvm-gcc4 to compensate for this should be available in the next day or so, depending on when it gets committed and updated. If you're maintaining a language front end or other llvm-based software, you'll

The vnot PatFrag uses ImmAllOnesV which should put an OPC_CheckImmAllOnesV in the matcher table. And the matcher table should call ISD::isBuildVectorAllOnes. I believe we use vnot with vXi1 vectors on X86 and I haven't seen any issues. The FIXME you pointed to seems related to a scalar patcher not a vector pattern. In that case the issue is that the immediate matcher for scalars calls

Another question, I need to get the "%0" below in the: %0 = tail call i32 (...)* @__FFF (i32 8) nounwind; <i32> [#uses=1] that is, the return register. I am wondering in general, where should I look in the llvm codebase for parsing instructions ? I am looking at existing passes and also the header files like Function.h, etc to see what methods they have, but it takes a while

A constant i1 is stored as a one bit APInt wrapped in a ConstantInt which is then wrapped in ConstantSDNode for SelectionDAG. The BUILD_VECTOR will just point to the same ConstantSDNode for each element. There is no concept of a sign in the storage. It's just a bit. Whether or not its treated as 1 or negative 1 is going to depend on the code looking at the value including printing code. And

Hi Kevin, To get some portion of a constant immediate you can use SDNodeXForms to transform constant SDNodes into other values. For a worked example, in the MIPS backend we use this for constant synthesis by materializing the value into a register: (From lib/Target/MipsInstrInfo.td): // Transformation Function - get the lower 16 bits. def LO16 : SDNodeXForm<imm, [{ return getImm(N,

Hi, It seems that opt thinks that the two pointers %_tmp2 = getelementptr [3 x i16], [3 x i16]* %a, i16 0, i64 1 and %_tmp4 = getelementptr [3 x i16], [3 x i16]* %a, i16 0, i16 1 does not alias? Is this intended or a bug? Details below: -------------- I found this when I ran opt on: define i16 @f () { %a = alloca [3 x i16] ; Write 98 at index 1 in the array. ; NB: using i64 as

Most probably you need to properly specify the calling convention the backend is using for calling the runtime functions. Or implement the stub for udivti3 that performs the necessary argument lifting. I guess there is no standard ABI document describing the intended calling convention here, so I'd just do what mingw64 does here and make everything here compatible. On Thu, Apr 26, 2018 at

On Thu, Apr 26, 2018 at 3:44 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Most probably you need to properly specify the calling convention the > backend is using for calling the runtime functions. Thanks for the tip. Can you be more specific? Are you suggesting there is some config parameter I can set before running TargetMachineEmitToFile? Do you know what

I think from the C compiler's point of view, it is going to want it to work for any size above an i64, i.e. all the way up to an i128 so that if the user of the C compiler does this computation with __uint128_t's then it will Do The Right Thing TM. Basically, you want unsigned long a, b, c, d; .... const __uint128_t u = (__uint128_t) a + b; const unsigned long v = u >> 64; const