Displaying 7 results from an estimated 7 matches for "take_addr".
Did you mean:
take_addr2
2004 Apr 23
2
[LLVMdev] subtle problem with inst_iterator
...now is to populate
> worklists, which allows us to do:
>
> std::set<Instruction*> WorkList(inst_begin(F), inst_end(F));
Maybe this can be rewritten like;
std::set<Instruction*> WorkList;
std::transform(insn_begin(F), insn_end(F),
inserter(WorkList, WorkList.begin(), take_address);
given proper definition of take_addres. Or maybe manual initialization will
okay.
So, if you think making inst_iterator's operator* return reference to
instruction is better than making it return reference to pointer, I can take
a look at this.
- Volodya
2011 May 04
2
[LLVMdev] identifying all dependent instructions through multi-levels of def-use relationship
...getelementptr inbounds [65536 x i8]* @window, i32 0, i32 %91
; [4]
%93 = load i8* %92, align 1 ; [5]
%94 = zext i8 %93 to i32 ; [6]
%.masked = and i32 %89, 32736 ;[7]
%95 = xor i32 %94, %.masked ;[8]
%take_addr = getelementptr i32* @ins_h
%96 = bitcast i32* %take_addr to i8*
call void @bkp_memory(i8* %96, i32 4)
store i32 %95, i32* @ins_h, align 4
%97 = and i32 %90, 32767
%.sum39 = or i32 %95, 32768
%98 = getelementptr inbounds [65536 x i16]* @prev, i32 0, i32 %.sum39
%99 = load i16*...
2004 Apr 23
0
[LLVMdev] subtle problem with inst_iterator
...ich allows us to do:
> >
> > std::set<Instruction*> WorkList(inst_begin(F), inst_end(F));
>
> Maybe this can be rewritten like;
>
> std::set<Instruction*> WorkList;
> std::transform(insn_begin(F), insn_end(F),
> inserter(WorkList, WorkList.begin(), take_address);
>
> given proper definition of take_addres. Or maybe manual initialization will
> okay.
>
> So, if you think making inst_iterator's operator* return reference to
> instruction is better than making it return reference to pointer, I can take
> a look at this.
I do thin...
2011 May 05
0
[LLVMdev] identifying all dependent instructions through multi-levels of def-use relationship
...65536 x i8]* @window, i32 0, i32 %91
> ; [4]
> %93 = load i8* %92, align 1 ; [5]
> %94 = zext i8 %93 to i32 ; [6]
> %.masked = and i32 %89, 32736 ;[7]
> %95 = xor i32 %94, %.masked ;[8]
> %take_addr = getelementptr i32* @ins_h
> %96 = bitcast i32* %take_addr to i8*
> call void @bkp_memory(i8* %96, i32 4)
> store i32 %95, i32* @ins_h, align 4
> %97 = and i32 %90, 32767
> %.sum39 = or i32 %95, 32768
> %98 = getelementptr inbounds [65536 x i16]* @prev, i32 0, i32 %.s...
2004 Apr 23
0
[LLVMdev] subtle problem with inst_iterator
On Fri, 23 Apr 2004, Vladimir Prus wrote:
> and since result of *it is considered to be rvalue it can't be accepted by
> this operator. The complete discussion is in
>
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
>
> I'd suggest to apply the following patch which makes operator* return
> reference to pointer. It makes my code compile and the rest
2004 Apr 27
2
[LLVMdev] subtle problem with inst_iterator
...> > std::set<Instruction*> WorkList(inst_begin(F), inst_end(F));
> >
> > Maybe this can be rewritten like;
> >
> > std::set<Instruction*> WorkList;
> > std::transform(insn_begin(F), insn_end(F),
> > inserter(WorkList, WorkList.begin(), take_address);
> >
> > given proper definition of take_addres. Or maybe manual initialization
> > will okay.
> >
> > So, if you think making inst_iterator's operator* return reference to
> > instruction is better than making it return reference to pointer, I can
> &...
2004 Apr 23
2
[LLVMdev] subtle problem with inst_iterator
Hello, I think there's a rather subtle problem with the inst_iterator. It
declares its iterator category as std::bidirectional_iterator_tag but C++
standard requirements for forward iterator (which are included in
requirements for bidirection iterator), say that the type of expression
*r;
should be T&, where 'r' is the iterator and T is its value type. The
inst_iterator,