similar to: [LLVMdev] Constant folding inttoptr i32 0 to null pointer?

On Tue, Jun 9, 2015 at 12:32 PM, David Majnemer <david.majnemer at gmail.com> wrote: > 'load volatile i32 addrspace(1)* null' seems fine to me. However, it > looks like instcombine will turn: > define i32 @foo() { > entry: > %std_ld.i = load volatile i32, i32 addrspace(1)* null > ret i32 %std_ld.i > } > > into: > define i32 @foo() { > entry:

Thanks David, It turns out, that the address space I was using was not 0, and yet the pointer was constant folded to null. Here is the sequence: Unoptimized code: define i32 @foo() #0 { entry: %address.addr.i = alloca i32, align 4 %value.i = alloca i32, align 4 store i32 0, i32* %address.addr.i, align 4 %0 = load i32* %address.addr.i, align 4 %1 = inttoptr i32 %0 to i32 addrspace(1)*

Devang Patel wrote: > On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > >> I got the current version of LLVM via svn yesterday and modified my >> code to >> use the LLVMFoldingBuilder. Very nice! >> >> My question is this: I noticed that the folding builder doesn't fold >> some >> operations, e.g. casts. Is there some reason why? If

On Jan 23, 2013, at 4:04 , "Benyei, Guy" <guy.benyei at intel.com> wrote: > Hi Ankur, > Since you use –Xclang, the clang executable passes multiple triples to “clang -cc1”. You can see that if you add the -v option. I’m sure there is someone here who can explain it better than I… > Anyhow, I think you better use clang -cc1. Make sure -cc1 is the first command line option

Hello everyone, Thanks a lot for the help. -target nvptx worked great with llvm-3.2. However it gives error with -target spir. LLVM/Clang trunk although works good for both options ( probably because spir is still work in progress ). Thanks again. - Ankur On Thu, Jan 24, 2013 at 12:43 PM, Benyei, Guy <guy.benyei at intel.com> wrote: > Hi Jordan,**** > > You’re right, and

Hi Jordan, You're right, and the driver -target option works perfectly with the SPIR triples. Thanks Guy Benyei [email_signature_guy_new2] From: Jordan Rose [mailto:jordan_rose at apple.com] Sent: Wednesday, January 23, 2013 19:47 To: Benyei, Guy Cc: ankur deshwal; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [cfe-dev] OpenCL SPIR/NVPTX code generation On Jan 23, 2013, at

Hello, I'd like to implement the gnu attribute "scalar_storage_order" to mark structs with non-native endianness. My rational is working on network protocols over little endian architecture (for instance: RiscV). An old bug is open on this issue here: https://bugs.llvm.org/show_bug.cgi?id=35293 I'd like to discuss the possible ways to implement this. The GCC implementation is

Hi Guy, Thanks a lot for the clarification. I tried using the triple for SPIR as $ clang -x cl -fno-builtin -emit-llvm -c -Xclang -triple -Xclang spir-unknown-unknown Simple_Kernel.cl However I get the following error. error: unknown target triple 'spir-unknown-unknown', please use -triple or -arch I also tried with triple nvptx-unknown-unknown clang -x cl -fno-builtin -emit-llvm -S

On Wed, Sep 19, 2012 at 5:43 AM, Benyei, Guy <guy.benyei at intel.com> wrote: > Ouriel, Boaz wrote: > > > ... > > > *** Richard Smith, Eli Friedman & Nadav Rotem: Portability Issues *** > > *****comment 1: int does_this_compile[sizeof(void*) - 3]; > Answer: We are discussing this internally and will provide an answer soon. >

Hi All, I have made an attempt to summarize the different comments that were raised so far. An answer has been provided inside. Please let me know if I missed any comments or got them wrong. *** Hal Finkel: Handling FP_CONTRACT *** *****Comment: The current specification provides a mechanism for handling FP_CONTRACT, but does so only at the module level. After much debate,

Ouriel, Boaz wrote: ... *** Richard Smith, Eli Friedman & Nadav Rotem: Portability Issues *** *****comment 1: int does_this_compile[sizeof(void*) - 3]; Answer: We are discussing this internally and will provide an answer soon. ****comment 2: struct how_do_you_represent_this_in_IR {

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 ;

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

hi, i am writing a simple LLVM pass to analyze the Store instruction. my pass derives from InstVisitor class, and the method to handle Store instruction is like this: void MyPass::visitStoreInst(StoreInst &I) { ... } It is pretty simple to handle Store. however, in on test i got an instruction like below: store i8 %tmp5, i8* inttoptr (i32 301959828 to i8*) the second operand is

On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > >> Hi, >> Is it correct to convert, >>   %196 = load i32* %195, align 8                  ; <i32> [#uses=1] >>   %197 = zext i32 %196 to i64                     ; <i64> [#uses=1] >>   %198 = ptrtoint i8* %193 to i64                 ; <i64> [#uses=1]

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

On Mon, Apr 4, 2011 at 7:10 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/4/2011 6:45 PM, Eli Friedman wrote: >> >> On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> >>  wrote: >>> >>>> Hi, >>>> Is it correct to convert, >>>>   %196 = load i32* %195, align 8                

On 4/4/2011 6:45 PM, Eli Friedman wrote: > On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote: >> >>> Hi, >>> Is it correct to convert, >>> %196 = load i32* %195, align 8 ;<i32> [#uses=1] >>> %197 = zext i32 %196 to i64 ;<i64> [#uses=1] >>> %198 =

Consider the two functions bellow: define i8* @f(i8* %A) { %pti = ptrtoint i8* %A to i64 %add = add i64 %pti, 5 %itp = inttoptr i64 %add to i8* ret i8* %itp} define i8* @g(i8* %A) { %gep = getelementptr i8* %A, i64 5 ret i8* %gep} What, if anything, prevents us from canonicalizing @f to @g?I've heard that this might be in violation of http://llvm.org/docs/LangRef.html#pointeraliasing

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,