Displaying 6 results from an estimated 6 matches for "mapperfectlyalia".
Did you mean:
mapperfectlyalias
2015 Aug 19
3
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
...lies on this behavior: it emits
llvm.memcpys for aggregate copies, despite the possibility of
self-assignment.
Going forward, llvm.memcpy calls emitted for aggregate copies would have
mayPerfectlyAlias set to '1'. Other uses of llvm.memcpy (including
lowerings from memcpy 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 the...
2015 Aug 19
2
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
...vior: it emits llvm.memcpys for aggregate copies, despite the possibility of self-assignment.
>>
>> Going forward, llvm.memcpy calls emitted for aggregate copies would have mayPerfectlyAlias set to '1'. Other uses of llvm.memcpy (including lowerings from memcpy 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::SimplifyMemTransf...
2015 Aug 19
3
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
...>> self-assignment.
>>>>
>>>> Going forward, llvm.memcpy calls emitted for aggregate copies
>>>> would have mayPerfectlyAlias set to '1'. Other uses of
>>>> llvm.memcpy (including lowerings from memcpy 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
>>>>...
2015 Aug 20
3
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
...t; llvm.memcpys for aggregate copies, despite the possibility of
> self-assignment.
>
> Going forward, llvm.memcpy calls emitted for aggregate copies
> would have mayPerfectlyAlias set to '1'. Other uses of
> llvm.memcpy (including lowerings from memcpy 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::Simpl...
2015 Aug 21
3
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
...copies, despite the possibility of
> > self-assignment.
> >
> > Going forward, llvm.memcpy calls emitted for aggregate copies
> > would have mayPerfectlyAlias set to '1'. Other uses of
> > llvm.memcpy (including lowerings from memcpy 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 (Se...
2015 Sep 08
2
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
...y of
> > > self-assignment.
> > >
> > > Going forward, llvm.memcpy calls emitted for aggregate copies
> > > would have mayPerfectlyAlias set to '1'. Other uses of
> > > llvm.memcpy (including lowerings from memcpy 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/stor...