similar to: [LLVMdev] The definition of getTypeSize

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.

On Oct 8, 2007, at 12:47 PM, Duncan Sands wrote: > 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

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

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

Hi, The lli interpreter crashed for the following case: ; ModuleID = 'x.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i686-pc-linux-gnu" define i32 @main() { entry: %retval = alloca i32 ; <i32*> [#uses=2] %tmp = alloca i32 ;

In the situation where a partial word is tested, lets say >0, by shifting left to get the sign bit into the msb and testing llvm is inserting a spurious right shift instruction. For example this IR: ... %0 = load i64* %a.addr, align 8 %shl = shl i64 %0, 28 %cmp = icmp sgt i64 %shl, 0 ... results in ... shlq $28, %rdi sarq $28, %rdi ; <<< spurious shift

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 = (

[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 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

When I have to do arithmetic, using APInt, with the component parts of a SCEV *X, I've been using X->getType()->getIntegerBitWidth() to tell me how many bits to allocate in my APInts. Now I've come across a case where the SCEV has a pointer type. How can I find the width of a pointer in bits? Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed...

Sure. David, what do you think about merging this to 3.9? Sanjay: are you saying I'd just apply that diff to InstructionSimplify.cpp, not InstCombineSelect.cpp? On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: > Hi Hans - > > Yes, I think this is a good patch for 3.9 (cc'ing David Majnemer as code > owner). The functional change was

Hi John, Thank you a lot. That clarifies some my confusions. What I want to do is to use both methods, get ALL struct allocation and a SPECIFIC struct allocation, at different situations. Here, I've got a couple of more questions. 1. For getting ALL struct allocation, when I use if( (AI = dyn_cast<AllocaInst>(&*i)))

Sanjay: let me know if this is something that will apply to 3.9. Thanks, Hans On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Quick update - the bug existed before I refactored that chunk in > InstSimplify with: > https://reviews.llvm.org/rL275911 > > In fact, as discussed in https://reviews.llvm.org/D22537 - because we have a

> Please review the 2.5 release notes here: http://llvm.org/docs/ReleaseNotes.html The description of nocapture is a bit funny: "... pointer arguments to functions that access through but do not return the pointer in a data structure that out lives the call" I think it needs s/return/retain/ and s/out lives/outlives/ > In addition, many APIs have changed in this release. Some

Hi Chandler, > void > foo () { > float x __attribute__ ((mode (XF))); > } nice reduction. I don't see any problem on x86-32, and I don't have access to an x86-64 box right now. Can you please open a PR for this, and also run in the debugger. When you hit the abort, use "up" to go up a stack frame or two or three, and print out the gcc types [use: call

David, Sanjay: ping? On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org> wrote: > Sure. David, what do you think about merging this to 3.9? > > Sanjay: are you saying I'd just apply that diff to > InstructionSimplify.cpp, not InstCombineSelect.cpp? > > On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: >> Hi

LGTM On Wednesday, July 27, 2016, Hans Wennborg <hans at chromium.org> wrote: > David, Sanjay: ping? > > On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org > <javascript:;>> wrote: > > Sure. David, what do you think about merging this to 3.9? > > > > Sanjay: are you saying I'd just apply that diff to > >

Bam. This is about as reduced as it gets. I think I can spot the problem point: chandlerc at osiris ~/code/compilers/build/llvm-gcc $ cat testcase.i void foo () { float x __attribute__ ((mode (XF))); } chandlerc at osiris ~/code/compilers/build/llvm-gcc $ ./gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const

Bruno Cornec via Syslinux said on Sun, Oct 25, 2015 at 12:39:53PM +0100: >I'm indeed trying to have everything I need on the boot part of the >ISO9660 image (kernel and an initrd which is normally built by >MondoRescue which then mounts the ISO9660 FS to have access to >additional content once booted). For now I do not seem to get to boot the >kernel. > >My machines are HP