Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] GEP vs IntToPtr/PtrToInt"
2011 Apr 05
3
[LLVMdev] GEP vs IntToPtr/PtrToInt
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]
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
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]
> %199 = add i64 %198, %197 ; <i64> [#uses=1]
> %200 = inttoptr i64 %199 to i8*
2011 Apr 04
2
[LLVMdev] GEP vs IntToPtr/PtrToInt
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 =
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
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
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
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 ;
2011 Apr 20
4
[LLVMdev] GEP vs IntToPtr/PtrToInt
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."
So this means the conversion discussed here is still safe in terms of
memory safety, but its meaning after conversion
2011 Apr 20
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
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."
>
2011 Apr 20
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
On 4/20/11 10:08 AM, Jianzhou Zhao 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."
I don't think the pointer aliasing rules
2011 Apr 20
2
[LLVMdev] GEP vs IntToPtr/PtrToInt
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
2011 Apr 20
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Wed, Apr 20, 2011 at 10:21 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> 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
2011 Apr 20
1
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Wed, Apr 20, 2011 at 2:11 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, Apr 20, 2011 at 10:21 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> 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
2014 Aug 31
3
[LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr
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
2014 Sep 10
3
[LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr
On 09/08/2014 04:22 PM, Dan Gohman wrote:
> An object can be allocated at virtual address 5 through extra-VM means
> (eg. mmap), and then one can (creatively) interpret the return value
> of @f as being associated with whatever %A was associated with *and*
> 5. The return value of @g can only be associated with exactly the same
> set that %A was associated with. Consequently,
2011 Apr 05
3
[LLVMdev] Incompatible types at call site
Hi,
For a call like this,
%tmp6 = call i32 (...)* bitcast (i32 (i8*, i8, i8**)* @ssplit to i32
(...)*)(i8* %tmp599, i32 46, i8** %domainv3) nounwind ; <i32>
does the 2nd argument get zero extended or sign extended?
Thanks,
Arushi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2010 Mar 09
3
[LLVMdev] Alignment for Alloca Inst in llvm 2.6
Hi,
1. Does the alignment of the pointer returned by an AllocaInst depend on the
instructions before it in the basic block? The 1st snippet below aligns 'a'
correctly, while the 2nd one doesnt. (the method handle_args, only prints
out the values of arguments, and returns argv unchanged).
define i32 @main(i32 %argc, i8** %argv) nounwind {
entry:
%argc_addr = alloca i32
2012 Feb 29
0
[LLVMdev] getelementptr being lowered to ptrtoint/.../inttoptr?
On Wed, Feb 29, 2012 at 11:00 AM, Dillon Sharlet <dsharlet at gmail.com> wrote:
> Hello,
>
> I am working on an application of LLVM where I would strongly prefer that
> getelementptr not be lowered into pointer arithmetic by any passes other
> than my own. I'm writing a ModulePass.
>
> I am observing a situation where I compile a C++ file with no optimization
>
2012 Feb 29
2
[LLVMdev] getelementptr being lowered to ptrtoint/.../inttoptr?
Hello,
I am working on an application of LLVM where I would strongly prefer that
getelementptr not be lowered into pointer arithmetic by any passes other
than my own. I'm writing a ModulePass.
I am observing a situation where I compile a C++ file with no optimization
and I get code as I would expect that uses getelementptr. However, if I
enable optimization with -O3, *some* of my
2010 Dec 13
1
[LLVMdev] How can I determine safely if a CallSite is "live" in a DSGraphs context
Hi,
I believe shouldHaveNodeForValue() should return false for
ConstantPointerNullValue.
Fixed in r121707.
Arushi
On Mon, Dec 13, 2010 at 12:10 PM, Kevin Streit
<kevin.streit at googlemail.com>wrote:
> I'm using BUDataStructures... But I tried LocalDatastructures and it didn't
> work either...
> On Dec 13, 2010 6:52 PM, "Arushi Aggarwal" <arushi987 at
2011 Aug 17
2
[LLVMdev] Is va_arg deprecated?
FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg
flag to Clang.
Applies against mainline.
(As discussed, va_arg isn't really supported well so this probably
doesn't work well on anything other than simple code, YMMV, etc)
~Will
On Thu, May 12, 2011 at 12:29 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote:
> Have these changes made it to mainline? Is
2017 Jun 20
3
LoopVectorize fails to vectorize loops with induction variables with PtrToInt/IntToPtr conversions
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