search for: simplifymemtransfer

...calls) would have mapPerfectlyAlias set to '0'. This change is motivated by poor optimization for small memcpys on targets with strict alignment requirements. When a user writes a small, unaligned memcpy we may transform it into an unaligned load/store pair in instcombine (See InstCombine::SimplifyMemTransfer), which is then broken up into an unwieldy series of smaller loads and stores during legalization. I have a fix for this issue which tags the pointers for unaligned load/store pairs with noalias metadata allowing CodeGen to produce better code during legalization, but it's not safe to apply whi...

...regate, we leave resulting loads and stores undecorated, meaning optimization of such instructions cannot benefit from TBAA. Furthermore, our analysis indicates that the only place where !tbaa.struct tags may potentially impact code generation is simplification of memcpy() and memmove() calls, see SimplifyMemTransfer() in InstCombineCalls.cpp. Ironically, what the code that makes that sole use of such tags is trying to do is to construct a !tbaa tag from the information encoded in the given !tbaa.struct tag. Note that it can only do that if the !tbaa.struct tag describes a structure with a single member of a sc...

...issing some information that is essential for that purpose? > >  -Hal > >> >> Furthermore, our analysis indicates that the only place where >> !tbaa.struct tags may potentially impact code generation is >> simplification of memcpy() and memmove() calls, see >> SimplifyMemTransfer() in InstCombineCalls.cpp. Ironically, what >> the code that makes that sole use of such tags is trying to do is >> to construct a !tbaa tag from the information encoded in the >> given !tbaa.struct tag. Note that it can only do that if the >> !tbaa.struct tag describes a st...

Consider the following IR example: define void @simple([4 x double] *%ptr, i64 %idx) { %stack = alloca [4 x double] %ptri8 = bitcast [4 x double] *%ptr to i8* %stacki8 = bitcast [4 x double] *%stack to i8* call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%stacki8, i8 *%ptri8, i32 32, i32 0, i1 0) %dataptr = getelementptr inbounds [4 x double], [4 x double] *%ptr, i32 0, i64 %idx

...mapPerfectlyAlias set to '0'. >> >> This change is motivated by poor optimization for small memcpys on targets with strict alignment requirements. When a user writes a small, unaligned memcpy we may transform it into an unaligned load/store pair in instcombine (See InstCombine::SimplifyMemTransfer), which is then broken up into an unwieldy series of smaller loads and stores during legalization. I have a fix for this issue which tags the pointers for unaligned load/store pairs with noalias metadata allowing CodeGen to produce better code during legalization, but it's not safe to apply whi...

...for that >> purpose? >> >>  -Hal >> >>> >>> Furthermore, our analysis indicates that the only place where >>> !tbaa.struct tags may potentially impact code generation is >>> simplification of memcpy() and memmove() calls, see >>> SimplifyMemTransfer() in InstCombineCalls.cpp. Ironically, what >>> the code that makes that sole use of such tags is trying to do is >>> to construct a !tbaa tag from the information encoded in the >>> given !tbaa.struct tag. Note that it can only do that if the >>> !tbaa.struct ta...

...is motivated by poor optimization for small memcpys on >>>> targets with strict alignment requirements. When a user writes a >>>> small, unaligned memcpy we may transform it into an unaligned >>>> load/store pair in instcombine (See >>>> InstCombine::SimplifyMemTransfer), which is then broken up into >>>> an unwieldy series of smaller loads and stores during >>>> legalization. I have a fix for this issue which tags the pointers >>>> for unaligned load/store pairs with noalias metadata allowing >>>> CodeGen to produce...

...yAlias set to '0'. > > This change is motivated by poor optimization for small memcpys on > targets with strict alignment requirements. When a user writes a > small, unaligned memcpy we may transform it into an unaligned > load/store pair in instcombine (See > InstCombine::SimplifyMemTransfer), which is then broken up into > an unwieldy series of smaller loads and stores during > legalization. I have a fix for this issue which tags the pointers > for unaligned load/store pairs with noalias metadata allowing > CodeGen to produce better code during legalization, but it's n...

...Hal >>>> >>>>> >>>>> Furthermore, our analysis indicates that the only place where >>>>> !tbaa.struct tags may potentially impact code generation is >>>>> simplification of memcpy() and memmove() calls, see >>>>> SimplifyMemTransfer() in InstCombineCalls.cpp. Ironically, what >>>>> the code that makes that sole use of such tags is trying to do is >>>>> to construct a !tbaa tag from the information encoded in the >>>>> given !tbaa.struct tag. Note that it can only do that if the >...

...; > > > This change is motivated by poor optimization for small memcpys on > > targets with strict alignment requirements. When a user writes a > > small, unaligned memcpy we may transform it into an unaligned > > load/store pair in instcombine (See > > InstCombine::SimplifyMemTransfer), which is then broken up into > > an unwieldy series of smaller loads and stores during > > legalization. I have a fix for this issue which tags the pointers > > for unaligned load/store pairs with noalias metadata allowing > > CodeGen to produce better code during legaliza...

...s change is motivated by poor optimization for small memcpys on > > > targets with strict alignment requirements. When a user writes a > > > small, unaligned memcpy we may transform it into an unaligned > > > load/store pair in instcombine (See > > > InstCombine::SimplifyMemTransfer), which is then broken up into > > > an unwieldy series of smaller loads and stores during > > > legalization. I have a fix for this issue which tags the pointers > > > for unaligned load/store pairs with noalias metadata allowing > > > CodeGen to produce better...