similar to: [LLVMdev] Inconsistency in the LLVM docs

Hi Micah, We need to fix the documentation here. We want to be able to convert vectors of integers to vectors of pointers and back. There are a few tests such as (/InstCombine/vector_gep1.ll) that check for these conversions. Nadav On Oct 10, 2012, at 11:11 AM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > http://llvm.org/docs/LangRef.html#i_inttoptr > >

Yes I know, I'm having problems with these tests because they violate the documentation. :) Micah From: Nadav Rotem [mailto:nrotem at apple.com] Sent: Wednesday, October 10, 2012 11:52 AM To: Villmow, Micah Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Inconsistency in the LLVM docs Hi Micah, We need to fix the documentation here. We want to be able to convert vectors of integers to

Introduction: We would like to add new keyword to 'sdiv'\'udiv' instructions i.e. 'no-overflow'. This is the updated solution devised in the discussion: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118257.html The proposed keywords: "nof" stands for 'no-overflow' Syntax: <result> = sdiv nof <ty> <op1>,

Thank you Chris, That is great news... So his modifications are in llvm-2.2? How has Christopher tested them? Are there attributes or intrinsics that I can also use? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, January 29, 2008 9:23 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] C

Hi all, I know it's a tiny thing, but this is the second time I'm noticing it so I'm just submitting a patch. There's a comma missing over there. Cheers, Bram Geron --- docs/LangRef.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/LangRef.html b/docs/LangRef.html index eba4e5a..5bc81cc 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@

Hello, I'm developing a C compiler for a machine with different local memories, for which I need to be able to specify in which specific memory a global variable should be allocated, and I also need to generate different instructions for accessing different local memories. I've seen in the LLVM 2.2 release notes that there is now support for multiple address spaces, that seem to

Alireza, I have added full support for embedded C address spaces to the LLVM IR (see http://llvm.org/docs/LangRef.html#t_pointer). I have not added any support for the fractional types and their operators, though I think this would simply require adding the necessary intrinsics, which is one of the easier things to add to LLVM. Given that LLVM takes the approach of modeling these kinds

Christopher, Thank you for all the work :-) Regarding the regression testing, it is in our plan to contribute into LLVM. The current state of our project is not in the form that we can do this at this time though, but I'm hoping that we can get some minimal functionality into LLVM before LLVM 2.3 (at most LLVM 2.4) release. Looks like you have also (at least on your local project) taken

First off, most of my information about the integer representation in LLVM is from http://llvm.org/docs/LangRef.html#t_integer and I could use some things cleared up. First, I guess that smaller integer sizes, say, i1 (boolean) are stuffed into a full word size for the cpu it is compiled on (so 8bits, or 32 bits or whatever). What if someone made an i4 and compiled it on 32/64 bit windows/nix/bsd

Hi, What''s happening here? require ''windows/path'' require ''windows/unicode'' include Windows::Path include Windows::Unicode file_a = ''bar.txt'' file_w = multi_to_wide(file_a) p PathFindExtensionA(file_a) # ''.txt'' => OK p PathFindExtensionW(file_w) # ''.'' => WRONG Is Ruby chopping the

Intel??????????Whamcloud??????????Lustre???????????????Whamcloud???Lustre???????????? ????? 2012?10?30? ? 11?2? ???????? ??? ????????2? ??????A?8? ?????????????http://www.whamcloud.com/events/lustre-installation-and-administration-beijing-china/ ???????????????? The 1st Lustre Administration and Installation training in Great China area after Intel Corporation acquired Whamcloud will soon be

I have a model "Childmodel" that belongs_to two other models "Parent1" and "Parent2". "Parent1" "has_many :childmodels, :order => :positionp1" and "Parent2" "has_many :childmodels, :order => :positionp2". i.e. The child is independently positioned within each of its parents. This works fine and gets me the useful

On 06/20/2017 03:26 AM, Hal Finkel wrote: > Hi, Adrien, Hello Hal! Thanks for your answer! > Thanks for reporting this. I recommend that you file a bug report at > https://bugs.llvm.org/ Will do! > Whenever I see reports of missed optimization opportunities in the face > of ptrtoint/inttoptr, my first question is: why are these instructions > present in the first place? At

Hi, I am observing some incorrect behavior in basicaa, wherein two pointers that basicaa should determine to be MustAlias are ending up NoAlias - the other extreme :( I am blaming this on basicaa not handling inttoptr. Here is the relevant IR snippet. -------------------- %sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32 %sunkaddr37 = add i32 %sunkaddr36, 16 %sunkaddr38 = inttoptr i32

LLVM 2.7's ScalarEvolution.cpp has this scary comment: // It's tempting to handle inttoptr and ptrtoint as no-ops, however this can // lead to pointer expressions which cannot safely be expanded to GEPs, // because ScalarEvolution doesn't respect the GEP aliasing rules when // simplifying integer expressions. I think I understand what the comment is saying. If a GEP has

Hi again. I have a complex type system in my custom language that isn't easily representable as LLVM IR types, so I figured I could mostly get along with treating my types as i8* and doing the appropriate bitcasts and inttoptr instructions, and doing pointer arithmetic myself (by casting the pointers to ints, adding the appropriate byte offsets, and then casting back to pointers). However,

On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > I have a question about when we should apply these pointer aliasing > rules. Do the rules tell us when a load/store is safe? > "Any memory access must be done through a pointer value associated > with an address range of the memory access, otherwise the behavior is > undefined." >

On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> I have a question about when we should apply these pointer aliasing >> rules. Do the rules tell us when a load/store is safe? >> "Any memory access must be done through a pointer value

RFC: GEP as canonical form for pointer addressing I would like to propose that we designate GEPs as the canonical form for pointer addressing in LLVM IR before CodeGenPrepare. Corollaries 1) It is legal for an optimizer to convert inttoptr+arithmetic+inttoptr sequences to GEPs, but not vice versa. 2) Input IR which does not contain inttoptr instructions will never contain inttoptr

This code is generated for va_arg. %6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**> [#uses=1] %7 = load i8** %6, align 8 ; <i8*> [#uses=1] %8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0 ; <%struct.__va_list_tag*> [#uses=1] %9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0, i32 0 ;