search for: __position

...context of C++ STL) (i.e. a class containing a pointer to another class): %"struct.std::_List_const_iterator<int>" = type { %"struct.std::_List_node_base"* } (The form in the readable LLVM language) and a function definition (declaration): void _M_insert(iterator __position, const value_type& __x) { ... } By issuing this command: llvm-g++ -fno-exceptions -fno-inline -emit-llvm -c ... The compilation substitutes "__position.0" for "__position", as shown below: define linkonce_odr void @_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERK...

Hi Xiaolong, > The compilation substitutes "__position.0" for "__position", as shown below: > > define linkonce_odr void @_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi(%"struct.std::list<int,std::allocator<int> >"* %this, i64 %__position.0, i32* %__x) nounwind ssp { ... } names like this only exis...

Thanks, Duncan. > > The compilation substitutes "__position.0" for "__position", as shown below: > > > > define linkonce_odr void @_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi(%"struct.std::list<int,std::allocator<int> >"* %this, i64 %__position.0, i32* %__x) nounwind ssp { ... } > > names...

...t_const_iterator<int>", whereas the parameter > (after the compilation) is of type > "struct.std::_List_node_base"*. Evidently, llvm-g++ replaces the > original parameter with its sole field. This is understandable and the > LLVM output indicates this by using "__position.0" rather than > "__position". Further, llvm-g++ represents (bitcasts) the parameter > type "struct.std::_List_node_base"* as (into) i64. Though this may > be decoded by analyzing the meta data with the function, I believe > that llvm-g++ has conducted some tra...

...int>", whereas the parameter > > (after the compilation) is of type > > "struct.std::_List_node_base"*. Evidently, llvm-g++ replaces the > > original parameter with its sole field. This is understandable and the > > LLVM output indicates this by using "__position.0" rather than > > "__position". Further, llvm-g++ represents (bitcasts) the parameter > > type "struct.std::_List_node_base"* as (into) i64. Though this may > > be decoded by analyzing the meta data with the function, I believe > > that llvm-g++ ha...

...000080136eec7 in free () from /lib/libc.so.7 #3 0x00000000007cdf7d in deallocate (this=0xd2e178, __p=0xd561c0) at new_allocator.h:97 #4 0x00000000007cdfaf in _M_deallocate (this=0xd2e178, __p=0xd561c0, __n=4) at stl_vector.h:134 #5 0x00000000007d66ef in _M_fill_insert (this=0xd2e178, __position= {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at vector.tcc:381 #6 0x00000000007d676d in insert (this=0xd2e178, __position= {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at stl_vector.h:653 #7 0x00000000007d67f7 in resize (this=0xd2e178, __new_size=5, __x=@0x...

.../lib/libc.so.7 > #3 0x00000000007cdf7d in deallocate (this=0xd2e178, __p=0xd561c0) > at new_allocator.h:97 > #4 0x00000000007cdfaf in _M_deallocate (this=0xd2e178, __p=0xd561c0, > __n=4) > at stl_vector.h:134 > #5 0x00000000007d66ef in _M_fill_insert (this=0xd2e178, __position= > {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at > vector.tcc:381 > #6 0x00000000007d676d in insert (this=0xd2e178, __position= > {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at > stl_vector.h:653 > #7 0x00000000007d67f7 in resize (this=0xd2e1...

On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: > On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > >> Could you try this (massively hacky) patch out to see if it fixes >> your >> problem? >> >> > Alas, it didn't fix the problem: > Crumbs. I think that the analysis I told you before wasn't fully correct. I think I mentioned something

...call void @llvm.memmove.p0i8.p0i8.i64(i8* %call5.i.i, i8* %extbitcastS32_D, i64 %extumul_with_overflow.i.iS26_D, i32 8, i1 false) #9 br label %invoke.cont invoke.cont: ; preds = %if.then.i.i.i.i.i.i, %if.then4 %sub.ptr.rhs.cast.i = ptrtoint %class.Vector* %__position.coerce to i64 %sub.ptr.rhs.cast.iS35_D = ptrtoint <2 x %class.Vector*> %splatInsMapS35_D.splat to <2 x i64> %sub.ptr.sub.iS36_D = sub <2 x i64> %sub.ptr.rhs.castS8_D, %sub.ptr.rhs.cast.iS35_D %sub.ptr.div.iS37_D = sdiv <2 x i64> %sub.ptr.sub.iS36_D, <i64 24, i64 24&...

On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > >> On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> >>> Let us know if you would like extra eyes on the two PPC failures. >>> Many >>> of us have a lot of experience with C++. :-) Do you know where these >>> allocations are?

...0i8.i64(i8* %call5.i.i, i8* > %extbitcastS32_D, i64 %extumul_with_overflow.i.iS26_D, i32 8, i1 false) #9 > br label %invoke.cont > > invoke.cont: ; preds = > %if.then.i.i.i.i.i.i, %if.then4 > %sub.ptr.rhs.cast.i = ptrtoint %class.Vector* %__position.coerce to i64 > %sub.ptr.rhs.cast.iS35_D = ptrtoint <2 x %class.Vector*> > %splatInsMapS35_D.splat to <2 x i64> > %sub.ptr.sub.iS36_D = sub <2 x i64> %sub.ptr.rhs.castS8_D, > %sub.ptr.rhs.cast.iS35_D > %sub.ptr.div.iS37_D = sdiv <2 x i64> %sub.ptr.sub....

On 07/24/2015 03:42 AM, Benjamin Kramer wrote: >> On 24.07.2015, at 08:06, zhi chen <zchenhn at gmail.com> wrote: >> >> It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing

...t;std::pair<llvm::MachineInstr* const, std::pair<unsigned int, llvm::VirtRegMap::ModRef> > >, std::less<llvm::MachineInstr*>, std::allocator<std::pair<llvm::MachineInstr* const, std::pair<unsigned int, llvm::VirtRegMap::ModRef> > > >::erase (this=0x8d1afcc, __position={_M_node = 0x8d1c520}) at /usr/include/c++/4.0.0/bits/stl_iterator_base_funcs.h:994 #2 0x0073df9c in std::_Rb_tree<llvm::MachineInstr*, std::pair<llvm::MachineInstr* const, std::pair<unsigned int, llvm::VirtRegMap::ModRef> >, std::_Select1st<std::pair<llvm::MachineInstr* const...