search for: syeda

...s against it. (There is really no need for us to depend on libiconv. If it is deemed to risky, then I can dropped it.) From: Anton Korobeynikov <anton at korobeynikov.info> To: Kai Peter Nacke <kai.nacke at de.ibm.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>, Yusra Syeda <Yusra.Syeda at ibm.com> Date: 02.10.2020 19:08 Subject: [EXTERNAL] Re: [llvm-dev] [RFC] Adding a char set converter to Support library As far as I remember, libiconv is under LGPL. Will this cause any troubles? On Fri, Oct 2, 2020 at 7:13 PM Kai Peter Nacke via llvm-dev <l...

...or fatal, it can be lowered safely. MartinO From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Jones via llvm-dev Sent: 30 December 2016 00:28 To: Philip Reames <listmail at philipreames.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Zaara Syeda <syzaara at ca.ibm.com> Subject: Re: [llvm-dev] RFC: Inline expansion of memcmp vs call to standard library Can I make another suggestion: create an intrinsic for memory equality, e.g. llvm.memcmp_eq.p0i8.p0i8.i64(i8*a, i8*b, i64 len). This intrinsic would return zero if the memory regio...

...may very well get the code you > want. > > Using the psuedo instruction here feels messy. In particular, I don't > like the fact it basically opts out of all of the combines which might > further improve the lowering. > > Philip > > > On 12/29/2016 11:35 AM, Zaara Syeda via llvm-dev wrote: > > Currently on PowerPC, calls to memcmp are not expanded and are left as > library calls. In certain conditions, expansion can improve performance > rather than calling the library function as done for functions like memcpy, > memmove, etc. This patch *(**https:...

...en I tried this, the instructions were executed on entry to the function before the vector registers have been assigned. How do I add these instructions so they appear after .cfi_startproc but are not executed on entry to the function? Or is there another approach I need to take? Thanks, Zaara Syeda -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171006/666d7814/attachment.html>

...ly lowering and chains using branches, you may very well get the code you want. Using the psuedo instruction here feels messy. In particular, I don't like the fact it basically opts out of all of the combines which might further improve the lowering. Philip On 12/29/2016 11:35 AM, Zaara Syeda via llvm-dev wrote: > > Currently on PowerPC, calls to memcmp are not expanded and are left as > library calls. In certain conditions, expansion can improve > performance rather than calling the library function as done for > functions like memcpy, memmove, etc. This patch > *...

...that isn’t target specific if other targets would benefit from a more general infrastructure. Please provide feedback if this approach should be continued to implement the PowerPC specific memcmp expansions or whether the community is interested in devising a more general approach. Thanks, Zaara Syeda -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161229/1990fc64/attachment.html>

Hi! On z/OS, there is the need to convert strings from EBCDIC to UTF-8 and vice versa. Using the POSIX iconv functions has some challenges, so I created a small wrapper around this functionality to get the same result on all platforms. This functionality is required for reading and writing GOFF object files and can also be used in the frontend. I put up the code on Phabricator

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" ><div>Hello,<br><br>I notice some strange behavior with the LegacyPassManager. I’ve added a new pass requirement of BlockFrequencyInfoWrapperPass to lib/Transforms/IPO/GlobalOpt.cpp.<br>However,