search for: yinma

On Thu, Nov 7, 2013 at 11:02 AM, Yin Ma <yinma at codeaurora.org> wrote: > Hi John, > > > > It seems the dereferencing a NULL pointer is undefined behavior but > > Calling a function through a null pointer seems o.k. > What is the well defined behavior of calling a null function pointer? > > > If so , for...

...one round? Thanks, Yin From: Andrew Trick [mailto:atrick at apple.com] Sent: Thursday, March 14, 2013 9:42 AM To: Yin Ma Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please On Mar 13, 2013, at 4:37 PM, Yin Ma <yinma at codeaurora.org> wrote: Hi All, In the target I am working, we comes cross a situation that the loop strength reduction could deliver a better result but currently not, because 1. the algorithm narrows search space by winner registers without considering the target preferred...

----- Original Message ----- > From: "Yin Ma" <yinma at codeaurora.org> > To: "Andrew Trick" <atrick at apple.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, March 14, 2013 4:21:50 PM > Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please > > > > > > Hi Andy,...

Hi John, It seems the dereferencing a NULL pointer is undefined behavior but Calling a function through a null pointer seems o.k. If so , for this place, we need comment out the check. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 look at Notes from the October 2003 meeting. Yin From: John Criswell [mailto:criswell at illinois.edu] Sent: Wednesday,

...f Code Aurora Forum, > > hosted by The Linux Foundation > > There are no customers of yours that use Hexagon-V2 or Hexagon-V3 ?? > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 14 Mar 2013 14:21:50 -0700 > From: "Yin Ma" <yinma at codeaurora.org> > To: "'Andrew Trick'" <atrick at apple.com> > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent > Decision in LSR Please > Message-ID: <0d7f01ce20f9$f1530b20$d3f92160$@codeaurora....

On Mar 13, 2013, at 4:37 PM, Yin Ma <yinma at codeaurora.org> wrote: > Hi All, > > In the target I am working, we comes cross a situation that the loop strength reduction > could deliver a better result but currently not, because > 1. the algorithm narrows search space by winner registers without considering >...

Hi All, In the target I am working, we comes cross a situation that the loop strength reduction could deliver a better result but currently not, because 1. the algorithm narrows search space by winner registers without considering the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs) 2. Cost comparison solely favors the number register without considering other

Hi Duncan, Yes, exactly. However, we need define Opcode MIN/MAX Into ISDOpcodes.h. Do you like to add those two definitions Into the tree? Thanks, Yin -----Original Message----- From: Duncan Sands [mailto:duncan.sands at gmail.com] On Behalf Of Duncan Sands Sent: Tuesday, October 30, 2012 12:10 PM To: Yin Ma Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Any plan to

On Thu, Jan 28, 2016 at 3:06 PM, Jonathan Roelofs <jonathan at codesourcery.com > wrote: > > > On 1/28/16 4:00 PM, Yin Ma via cfe-dev wrote: > >> Hi David, >> >> I assume you have a powerful machine. Our drive space is on network >> mounted >> >> machined by IT department. The machine is default Ubuntu setup with 8 >> cores. >>

Hello, Do you have any plan to add MIN/MAX in ISD node? Atomic operations have Min/Max operator already. This should be easy to add Min/Max node in ISD list. Because after converting control flow into Min/Max operator, it will result in better optimization because associative attribute and can be moved around. Could you give some opinions on this issue? Thanks,

Hi Does anyone know if the shrink wrap pass works for ARM architecture? I tried it seems not working. Which architecture shrink warp was originally designed for? Thanks, Yin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131030/d2a4e878/attachment.html>

Hello, It seems there is the no redundancy elimination over loop iterations, such as predictive communing or scalar replacement in LLVM. They are quite usefully for computation code. I am wondering if any party is working or has plan to implement those optimizations? Thanks, Yin Qualcomm Innovation Center, Inc. is a member of Code

Hi Duncan, To use select, usually, there is a compare before select. Presence of comparison will disable some opportunities to optimize some code. Select and Compare is not associative neither. Thanks, Yin -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands Sent: Tuesday, October 30, 2012

Hi, For a small case, that calls NULL pointer function. LLVM explicitly converts It to a store because it thinks it is not reachable like calling undefvalue. In InstCombineCalls.cpp:930 I think it is not a right approach because calling null pointer function Will segfault the program. Converting to a store will make program pass Silently. This changes the behavior of a program.