similar to: [LLVMdev] Any plan to add MIN/MAX isd node?

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

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 Yin, > 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. at the IR level LLVM already has pattern matching helpers for identifying min/max idioms, here is part of a transform using this, from InstructionSimplify.cpp: // Signed variants

Hi Yin, > 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

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 this place, we need comment out the check. >

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,

On Thu, 11 Oct 2018 at 00:28, Thomas Lively via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I just wanted to bump this to see if anyone has any input. I would really like to get these landed soon if there are no objections. Hi Thomas, With ISD::FMINNAN and ISD::FMAXNAN now easy to produce for any target due to these newly exposed intrinsics, I think these nodes should be handled

----- 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, > > > > Actually,

Hey, I wanted to add an intrinsics to read MSRs. So I added the intrinsics and lowered it to a new ISD node I created ISD::RDMSR, its first operand is the MSR id. I added a case in X86DAGToDAGISel::Select for ISD::RDMSR. Now I know rdmsr works like so: mov r/ecx, <id> rdmsr r/eax holds the lower 32/64 bit >From what I understood this needs a Token Factor node, nodes which are

Alex, After looking into this a bit, it looks to me like the best thing to do for targets that do not natively support ISD::MINIMUM and ISD::MAXIMUM would be to fall back to a libcall, since implementing these operations in terms of existing operations is actually rather complicated. Do you think it would make sense to add builtin functions to compiler-rt to implement these operations, or is

LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. The library functions defined in RuntimeLibCalls.def (among others) are these: HANDLE_LIBCALL(SRA_I16, "__ashrhi3") HANDLE_LIBCALL(SRA_I32, "__ashrsi3") HANDLE_LIBCALL(SRA_I64, "__ashrdi3") However, setting

Hi Andy, Actually, if we just add hooks that preserves the existing behavior, It is not difficult. For example, For case one, we can define one function like virtual const SCEV* getTargetPreferredWinnerReg(const SCEV*& ScaledReg, SmallVector<const SCEV *, 4>& BaseRegs, GlobalValue*& BaseGV) const; In NarrowSearchSpaceByPickingWinnerRegs, we can

Hi Eli, Thanks for pointing to the CTLZ_ZERO_UNDEF “LibCall” implementation. I have not it in the version that I am currently using, so it’s nice to know that it’s implemented now. Incidentally, the CTLZ… implementation is IDENTICAL to what I am proposing for the Shifts. This is not just adding support for “out-of-tree-targets”, but giving consistency to the fact that we have perfectly defined

> On Jan 28, 2015, at 3:47 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- >> From: "Matt Arsenault" <Matthew.Arsenault at amd.com> >> To: "llvmdev at cs.uiuc.edu" <LLVMdev at cs.uiuc.edu> >> Sent: Wednesday, January 28, 2015 1:52:59 PM >> Subject: [LLVMdev] RFC: Add ISD nodes for mad >>

Hi Eli, First of all, please I would appreciate that you try to not confuse my limited use of English with stupidity or lack or criteria in other subjects. I’m not English native, so please keep that in mind. You have been significantly helpful in the recent past so please keep on. Interestingly, you made a mention of a related but not identical issue. It is true that most (or all) processors

Dear all, a couple of new generic DAG nodes ISD::ADCARRY and ISD::SUBCARRY were recently introduced in https://reviews.llvm.org/D29872 These nodes have three inputs and two outputs, the second output being the "carry". I understand that carry is well defined for ADDCARRY but my question is about SUBCARRY. Some architectures set the "carry" of a "x - y" subtraction

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. >>

Attached is a patch that renames ISD::BIT_CONVERT to ISD::BITCAST as per http://www.llvm.org/OpenProjects.html, #3 under Code Generator Improvements. I have not updated the OpenProjects.html file itself as I could not find that file in the source code. The patch itself also includes elimination of whitespace at the end of lines because my VIM settings do that automatically. If this is not desired

Dear All, I am trying to custom lower 32-bit ISD::SHL and SHR in a backend for 6502 family CPUs. The particular subtarget has 16-bit registers at most, so a 32-bit result is not legal. Normally, if you mark this as "Legal" or "Expand", then it will expand the node into a more nodes as follows in an example: shl i32 %a , 2 => high_sdvalue = (or (shr %b, 14), (shl %c, 2) )

Hi Yin, MCA does support the –mcpu and –mtriple options. We have one arm test in llvm/test/tools/llvm-mca/ARM for a cortex-9, which is an Out of Order chip. Hope that helps! -Matt From: Yin Liu <yinliu.tiger at gmail.com> Sent: Tuesday, May 8, 2018 2:49 PM To: Davis, Matthew <Matthew.Davis at sony.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Is there any relationship