similar to: LoopIdiomRecognize is not recognizing the ctpop idiom

Hi, Following is excerpted from http://llvm.org/releases/3.1/docs/LangRef.html#int_ctpop. How come the return type needs to be consistent with parameter type? i64/i128 seems to be overkill, and i8, i16 are inconvenient. ----------------------------------- declare i8 @llvm.ctpop.i8(i8 <src>) declare i16 @llvm.ctpop.i16(i16 <src>) declare i32 @llvm.ctpop.i32(i32

Quick question. The 'ISD::CTPOP' node allows a target to lower the counting of ones in a word to a single instruction. Our target also has an instruction for counting the zeroes in a word. Does CTPOP support counting of zeroes as well as ones instead of doing either "CTPOP(INVERT(operand))" or "N-bits - CTPOP(operand)"? Thanks, MartinO

Hello, is it correct, that the "llvm.ctpop" Hamming weight intrinsic is currently (LLVM 2.2) implemented in Line 254 in lib/CodeGen/IntrinsicLowering.cpp /// LowerCTPOP - Emit the code to lower ctpop of V before the specified /// instruction IP. static Value *LowerCTPOP(Value *V, Instruction *IP) { assert(V->getType()->isInteger() && "Can't ctpop a

On 1/18/2018 12:57 AM, ORiordan, Martin via llvm-dev wrote: > Quick question. The 'ISD::CTPOP' node allows a target to lower the counting of ones in a word to a single instruction. Our target also has an instruction for counting the zeroes in a word. Does CTPOP support counting of zeroes as well as ones instead of doing either "CTPOP(INVERT(operand))" or "N-bits -

On 27.10.2012, at 18:24, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 27.10.2012, at 18:15, Sean Silva <silvas at purdue.edu> wrote: > >> How does this affect freestanding implementations? > > This transform is disabled with -fno-builtin or -ffreestanding. Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is

Helper function: template<typename InsnType> static InsnType fieldFromInstruction(InsnType insn, unsigned startBit, unsigned numBits) { assert(startBit + numBits <= (sizeof(InsnType)*8) && "Instruction field out of bounds!"); InsnType fieldMask; if (numBits == sizeof(InsnType)*8) fieldMask =

I am new to the LLVM backends, I am wondering how instruction selection is done in LLVM backends, I looked at the .td files in Target/X86, they all seem to be small and do not deal with common X86 instructions, i.e. mov, push, pop, etc. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Sunil, I had filed a bug and saw your response stating that it would be fixed in version 14. In the meanwhile , what we want to know is whether this bug is a minor bug and can be ignored for now. Does reporting 100% inodes cause any problem for the OCFS file system or can we ignore this bug and go into production. Also can you tell us by when version 14 would be released. R'gds

Hi Chris, > Of interest may be this thesis. It talks about converting alpha code > to LLVM (among other things): > http://llvm.org/pubs/2004-05-JoshiMSThesis.html Thanks, it was of interest. I didn't spot its relevance from the title. Cheers, Ralph.

Output df -i ------------------ Filesystem Inodes IUsed IFree IUse% Mounted on / /dev/sde 348548 348195 353 100% /ocfsa01 /dev/sdf 348548 348195 353 100% /ocfsa02 /dev/sdg 348548 348195 353 100% /ocfsa03 /dev/sdk 139410 138073 1337 100% /ocfsq01 Output df -kP ----------------------- Filesystem

I think I might have found a bug in the exection engine's 'constants folding'. Basically APInt's parameters are the wrong way round. Line 577 for lib/ExecutionEngine/ExecutionEngine.cpp :- case Instruction::PtrToInt: { GenericValue GV = getConstantValue(Op0); uint32_t PtrWidth = TD->getPointerSizeInBits(); GV.IntVal = APInt(PtrWidth,

LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. The library functions defined in RuntimeLibCalls.def (among others) are these: HANDLE_LIBCALL(SRA_I16, "__ashrhi3") HANDLE_LIBCALL(SRA_I32, "__ashrsi3") HANDLE_LIBCALL(SRA_I64, "__ashrdi3") However, setting

Hello, I'm compiling LLVM with MSVC at the moment, I've got the following warning: BitstreamReader.h(327) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) in line uint64_t Piece = Read(NumBits); if ((Piece & (1U << (NumBits-1))) == 0) Is this warning relevant? Is also Read64()

I tried the following: - ConstantInt::get(Type::getInt64Ty(Ctx), APInt(0xFFFFFFFFFFFFFFFF, 64, false)) - ConstantInt::get(Type::getInt64Ty(Ctx), APInt(-1, 64)) I am receiving the following error: Assertion `NumBits <= MAX_INT_BITS && "bitwidth too large" failed -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed...

Hi, I have a Type * which may come from an IntegerType as shown below: Type.getIntegerBitWidth() tells me numBits. But how to extract the IntegerType.getSignBit? If pType isIntegerType, I need to know if it is signed or unsigned... How to achieve this? Thx Alex llvm::Type * getRandomValid_IntegerType(llvm::LLVMContext &C) { using namespace llvm; //--- determine num of bits

Hi, I want to compute the bitwise 'and' between two values of type int1:  %x = and %a, %b  . Which is the LLVM instruction that creates this? I only found the APInt class, whose constructor is:  APInt(unsigned numBits, uint64_t val, bool isSigned = false) and which provides the bitwise AND operation: APInt  llvm::APIntOps::And (const APInt &LHS, const APInt &RHS)   Bitwise

Currently f_fsid of struct kstatfs returned from ocfs2_statfs() is undefined (vfs layer fills 0 as default). Since in some conditions, f_fsid value might be used as (f_fsid, ino) pair to uniquely identify a file, ocfs2 should return a unique defined f_fsid value from ocfs2_statfs(). Because uuid_str is identified no mater on big or litlle endian machine, it's also endian consistent to use

Currently f_fsid of struct kstatfs returned from ocfs2_statfs() is undefined (at least it should be filled with 0). Since in some conditions, f_fsid value might be used as (f_fsid, ino) pare to uniquely identify a file, ocfs2 should return a defined unique f_fsid value from ocfs2_statfs(). This patch uses uuid_hash as a unique ID to initiate f_fsid value, the 32bits width is enough for ocfs2

Dear all, I have following kind of character vector: Vec <- c("344426", "dwjjsgcj", "123sgdc", "aagha123", "sdh343asgh", "123jhd51") Now I want to split each element of this vector according to?numeric?and string element. For example in the 1st element of that vector, there is no string element. Therefore I should get a vector of

<div> </div><div><div><p>Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more.</p><p>This proposal is to add a <code>llvm.clmul</code> instruction. Or if that is contentious, <code>llvm.experimental.bitmanip.clmul</code> instruction.