search for: int8ti

Hi Craig, On 03.07.19 17:33, Craig Topper wrote: > Don't the CreateICmp calls return a Value* with an i1 type? But then > they are added to an i8 type? Not sure that works.  I had that initially: auto cf = IRB.CreateICmpULT(Incr, ConstantInt::get(Int8Ty, 1)); auto carry = IRB.CreateZExt(cf, Int8Ty); Incr = IRB.CreateAdd(Incr, carry); it makes no difference to the generated assembly

Hello, I have an optimisation issue in an llvm IR pass - the issue being that unnecessary instructions are generated in the final assembly (with -O3). I want to create the following assembly snippet: mov dl,BYTE PTR [rsi+rdi*1] add dl,0x1 adc dl,0x0 mov BYTE PTR [rsi+rdi*1],dl however what is created is (variant #1): mov dl,BYTE PTR [rsi+rdx*1] add dl,0x1 cmp

Thank you Evan, I added the return Type::Int8Ty to the switch statement to get it to work. I don't know if this can have other consequences, I haven't yet verified if the generated Legalized DAG is correct though. A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 3:23 PM To:

On Sep 22, 2009, at 4:49 PM, Talin wrote: > > // Calculate the size of the specified LLVM type. > Constant * DebugInfoBuilder::getSize(const Type * type) { > Constant * one = ConstantInt::get(Type::Int32Ty, 1); > return ConstantExpr::getPtrToInt( > ConstantExpr::getGetElementPtr( > ConstantPointerNull::get(PointerType::getUnqual(type)), >

Hi Chris, > The static code generator works for many simple cases, but it is currently > disabled. To enable it, uncomment this line in > llvm-gcc/gcc/llvm-convert.cpp: > > //#define ITANIUM_STYLE_EXCEPTIONS > > > Based on that, you should be able to compile simple C++ codes that throw > and catch exceptions. The next step would be to make a .bc file, run it

On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com>wrote: > On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> > wrote: > > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: > >> So, one feature of the late, lamented DebugInfoBuilder that I am missing > >> quite badly, and which is not

On Oct 3, 2007, at 3:21 PM, Alireza.Moshtaghi at microchip.com wrote: > Thank you Evan, > I added the return Type::Int8Ty to the switch statement to get it to > work. > I don't know if this can have other consequences, I haven't yet > verified > if the generated Legalized DAG is correct though. If this works, please submit a patch. Otherwise please submit a bug

On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote: > So does that mean that LLVM can't lower automatically to 8-bit values? There is no inherent reason. LLVM should be able to lower to 8-bit values. It's probably a bug somewhere. In TargetLowering.h: bool isTypeLegal(MVT::ValueType VT) const { return !MVT::isExtendedVT(VT) && RegClassForVT[VT] !=

See the bug for a reduction and the gimple trees. validate_arglist definately is rejecting the arglist in EmitBuiltinAlloca. (try: bool TreeToLLVM::EmitBuiltinAlloca(tree exp, Value *&Result) { tree arglist = TREE_OPERAND(exp, 1); if (!validate_arglist(arglist, INTEGER_TYPE, VOID_TYPE)) { debug_tree(arglist); return false; } Value *Amt = Emit(TREE_VALUE(arglist), 0); Amt =

I am trying to verify the generated DAG after converting from llvm to DAG, however I'm not sure if this is correct or not. Here is the situation: In order to get LLVM to lower to 8-bit I have to define only 8-bit registers and the pointer size also to be 8-bit. Doing so, the attached DAG is generated for a load:i16. I have problem understanding this DAG in two places: 1)As you can see the

Thanks, I am now working on compiling up VMKit. When compiling VMKit in my up-to-date svn checkout I get several error messages on missing members of the class 'llvm::Type': PNetLib.cpp: In function ‘void decapsulePrimitive(n3::VMObject*, const llvm::Type*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> >&)’: PNetLib.cpp:694: error: ‘Int1Ty’ is not a

On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> wrote: > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: >> So, one feature of the late, lamented DebugInfoBuilder that I am missing >> quite badly, and which is not available in the current DIFactory, is the >> ability to specify structure offsets abstractly. The

So does that mean that LLVM can't lower automatically to 8-bit values? I tried defining 8-bit pointers in the subtarget using "p:8:8:8" but it asserts at line 566 of TargetData.cpp in the default case of TargetData::getIntPtrType() Is it difficult to add 8-bit support? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On

ok.. So I am trying out what you have suggested. I have written the below code which basically tries to write the constant 10 to a file. myprint is a function pointer to a function which takes char * parameter and writes it to file. Value *Ten = ConstantInt::get(Type::Int32Ty, 10); const Type *VoidPtrTy = PointerType::getUnqual(Type::Int8Ty); AllocaInst *AI = new AllocaInst(Type::Int32Ty); Value

On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: > > On Sep 22, 2009, at 4:49 PM, Talin wrote: > >> >> // Calculate the size of the specified LLVM type. >> Constant * DebugInfoBuilder::getSize(const Type * type) { >> Constant * one = ConstantInt::get(Type::Int32Ty, 1); >> return ConstantExpr::getPtrToInt( >>

I'm getting a 'function arguments must be value types' assertion from the following (abridged) code. Basically, I'm writing a pass that inserts llvm.frameaddress intrinsic calls everywhere 'interesting' that passes on the result by calling the C function void mcp_trace_stack(char *ptr). First I grab the functions themselves: Constant *MCPTraceStack,

On Oct 8, 2007, at 3:15 PM, Alireza.Moshtaghi at microchip.com wrote: > I am trying to verify the generated DAG after converting from llvm to > DAG, however I'm not sure if this is correct or not. > Here is the situation: > In order to get LLVM to lower to 8-bit I have to define only 8-bit > registers and the pointer size also to be 8-bit. > Doing so, the attached DAG is

On Fri, 6 Apr 2007, Nicolas Geoffray wrote: > Like you say, it's not functional for non-calls instructions. Besides, > having to change all CalInst to InvokeInst is just too much pain in our > current vm. ok. > Actually, why is it missing? What's the difference between the code > generator and the JIT? There are two things missing: 1. Testing and working out the set

Hi all, In several of the transformations I'm working on I need to embed the logical equivalent of puts/printf/etc. calls inline with code. I am having some difficulties getting the transformation code right. As I understand it, I should be creating a ConstantArray based on the string (in this case I'm taking an instruction, 'disassembling' it to an ostringstream then turning

On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: >> >> On Sep 22, 2009, at 4:49 PM, Talin wrote: >>> >>> // Calculate the size of the specified LLVM type. >>> Constant * DebugInfoBuilder::getSize(const Type * type) { >>>    Constant * one =