similar to: [LLVMdev] [CLang] Comparing vector types - invalid error and proposed fix

Hi Martin, On Oct 2, 2013, at 6:25 AM, Martin O'Riordan <Martin.ORiordan at movidius.com> wrote: > I was investigating an error diagnostic in the following test example: > > typedef signed char char16 __attribute__((ext_vector_type(16))); > > void test( char16 srcA, char16 srcB, char16 *dst) { > *dst = ( srcA == srcB ); > } > > which produces the

I was investigating an error diagnostic in the following test example: typedef signed char char16 __attribute__((ext_vector_type(16))); void test( char16 srcA, char16 srcB, char16 *dst) { *dst = ( srcA == srcB ); } which produces the message: mismatch.c:5:10: error: assigning to 'char16' from incompatible type 'char __attribute__((ext_vector_type(16)))' *dst = (

Where does the unsignedSub come from? On 2017-02-15 20:38, Ryan Taylor wrote: > Sorry, it should be: > > defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs, > GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>; > > On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> > wrote: > >> I see. If I put simm16 and

I see. If I put simm16 and immSExt16x in place of uimm16 and immZExt16x respectively, the imm matches but it prints out -32768 (which is invalid for sub16u). We are using uimm16 not match unsigned but for PrintMethod, effectively uimm16 and simm16 are both Operand<i16>. I'm still unclear why simm16 matches and uimm16 does not. Here is the pattern if that helps at all. So just as a

For example, given a multiclass for ADD 32 bit that might produce something like: ADD32_REG_REG_REG (operands are all registers for a 32 bit add) ADD32_REG_IMM_REG (srcA is a register, srcB is an immediate and dst is a register) ADD32_REG_IMM_MEM (srcA is a register, srcB is an immediate and dst is a memory address) What I'd like to do is replace an operand, for example, change srcA from a

It appears that it's impossible to duplicate a node in the dag. For example, there is some code: b = a * a; // a is a global int A LD node is generated for A and it goes into both Operand 0 and 1 of the MUL node. The issue is I'm trying to match a pattern of: set dstReg:$dstD (OpNode (srcAType (load addr32:$srcA)), (srcBType (load addr32:$srcB))) so basically a mem, mem, reg

Thanks for your reply. We are propagating sign info to tablegen currently using BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm. I imagine (I have not looked) they are printed according to instruction in AsmPrinter.cpp (pure speculation). I'm still confused as to why 0x7FFF is ok to match 16 bit int but not 0x8000? Thanks. On Wed, Feb 15, 2017 at 1:44 PM, Manuel Jacob <me at

Now that I'm working on codegen support for arbitrary precision integers (think i36 or i129), I've hit the problem of what getTypeSize and friends should return for such integers (the current implementations seem to me to be wrong). However it's not clear to me how getTypeSize and friends are defined. There seem to be several possible meanings for the size of a type (only talking

On Oct 7, 2007, at 11:23 AM, Duncan Sands wrote: > Now that I'm working on codegen support for arbitrary precision > integers (think i36 or i129), I've hit the problem of what > getTypeSize and friends should return for such integers (the > current implementations seem to me to be wrong). However it's > not clear to me how getTypeSize and friends are defined. > >

Hi Evan, thanks for replying. > > Now that I'm working on codegen support for arbitrary precision > > integers (think i36 or i129), I've hit the problem of what > > getTypeSize and friends should return for such integers (the > > current implementations seem to me to be wrong). However it's > > not clear to me how getTypeSize and friends are defined.

Evening, I was writing some code that tried to insert calls to the llvm.annotation intrinsic function, which has a signature of (i32, i8*, i8*, i32). The code is below. void addAnnotation( BasicBlock *block, Function *F) { string foo = "foo"; string bar = "barr"; Type *charTy = Type::getInt8Ty(block->getContext()); ArrayType *s1Ty =

Andrew Ruef wrote: > Evening, > > I was writing some code that tried to insert calls to the > llvm.annotation intrinsic function, which has a signature of (i32, > i8*, i8*, i32). The code is below. > > void addAnnotation( BasicBlock *block, Function *F) > { > string foo = "foo"; > string bar = "barr"; > > Type

On 05/10/2013 06:27 AM, syslinux-bot for Matt Fleming wrote: > > diff --git a/efi/main.c b/efi/main.c > index 31f0bff..27e7f8f 100644 > --- a/efi/main.c > +++ b/efi/main.c > @@ -1177,13 +1177,10 @@ static void efi_setcwd(CHAR16 *dp) > > EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *table) > { > + EFI_PXE_BASE_CODE *pxe; > EFI_LOADED_IMAGE *info;

http://bugs.freedesktop.org/show_bug.cgi?id=25966 Summary: nv25 : rxvt scrolling is very slow Product: xorg Version: 7.5 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

GEN usr/klibc/syscalls/SYSCALLS.i GEN usr/klibc/syscalls/syscalls.nrs GEN usr/klibc/syscalls/typesize.c KLIBCCC usr/klibc/syscalls/typesize.o OBJCOPY usr/klibc/syscalls/typesize.bin GEN usr/klibc/syscalls/syscalls.mk GEN usr/klibc/syscalls/SYSCALLS.i GEN usr/klibc/syscalls/syscalls.nrs GEN usr/klibc/syscalls/typesize.c KLIBCCC

> On Jun 15, 2015, at 7:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > To be more specific: > > We have some operators that we are currently implementing as intrinsics, for example things like: abs, min, max, etc..... > > for some code: > > int a; > > int food() > { > return abs(a); > } > > the corresponding operator should

I do not have a strong opinion on the naming of the various size functions, or on how to deal with APInt's of sizes that are not multiples of a byte. I do think loading and storing more bytes than necessary is generally a bad idea, especially if you're getting uninitialized bits. (If you incorrectly cross a page boundary, you might fault, for one thing. Watch out for packed

The following patchset implements 3 seperate series of changes. External Building ================= Patches 1 through 8 enable to use of klibc's build system while leaving the src tree pristine (and potentially read only). Specifically: - srctree=<Sources for klibc> - objtree=<Ouput directory for klibc> - KLIBCKERNELSRC=<Kernel sources> - KLIBCKERNELOBJ=<Kernel

[Reposted from llvm-bugs mailing list. Also has an updated, hopefully better, patch associated with it.] Hi, The following program causes the LLVM GCC4 front end to ICE: struct A { virtual ~A(); }; template <typename Ty> struct B : public A { ~B () { delete [] val; } private: Ty* val; }; template <typename Ty> struct C : public A { C (); ~C (); }; template

Hi Evan, > I think rather than worrying about how these functions are being used > *now* you should define them in a way that's clear and fix the > incorrect uses. To me that means: > > getTypeSizeInBits - actual size > getABITypeSizeInBits - ABI size when used in a larger structure > getStorageTypeSizeInBits - size of load / store I agree and will try to do