similar to: [LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please

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

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

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

I just want to know ,how can I developing a LLVM Pass on Windows' visual studio? I can develop a Pass on linux,but I can't do it on windows. 2013/3/15 <llvmdev-request at cs.uiuc.edu> > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide Web, visit >

Hi all, I have been looking at the code for both the zaptel driver (wctdm.c/wcfxs.c) and the asterisk channel driver (chan_zap.c) trying to figure out how much of this that has been implemented. So far I can see that the current stable 1.0.9.1 zaptel driver don't have the SETPOLARITY ioctl that would be required to properly signal the Swedish/Dutch CLIP, but the 1.2 beta1 has this

Hi, I was building LLVM with gcc 6.1.1 recently and it was spitting out some warnings relating to misleading indention that caught my eye. This wasn't a fresh build so I may have missed some. I've CC'ed the authors of the potentially misleading lines so they can decide what do about the warnings (if anything). I'm wondering if clang-format is making some inappropriate choices

I have a few questions regarding cost calculation in loop strength reduction. 1. Ignoring LSR uses of kind ICmpZero. These usually come from the loop latch conditions. On Hexagon most loops that would contain such a LSR use are going to be converted to hardware loops and the entire check will disappear. There is no need to analyze these cases in LSR. In fact, completely ignoring them improves

Hello, find enclosed a first patch for adding tail call optimizations for thumb1 targets. I assume that this list is the right place for publishing patches for review? Since this is my first proposal for LLVM, I'd very much appreciate your feedback. What the patch is meant to do: For Tail calls identified during DAG generation, the target address will be loaded into a register by use

[correction] On May 20, 2008, at 1:45 PM, Marcel Moolenaar wrote: > All, > > The following IR is causing the assert: > > \begin{ll} > ; ModuleID = 'x.bc' > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- > i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- > f80:128:128" > target triple =

All, The following IR is causing the assert: \begin{ll} ; ModuleID = 'x.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "ia64-portbld-freebsd8.0" define void @__ia64_set_fast_math() nounwind { entry: tail call void asm sideeffect "mov.m

Hi Justin, After catching up with LLVM trunk, I've encountered a new backend issue around i1. Is i1 support still incomplete? Bug report: http://llvm.org/bugs/show_bug.cgi?id=17519 Thanks, - D. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131009/4ca2cbdd/attachment.html>

All, This is hopefully the final drop of the patches for adding global heartbeat to the o2cb stack. The diff from the previous set is here: http://oss.oracle.com/~smushran/global-hb-diff-2010-10-07 Implemented most of the suggestions provided by Joel and Wengang. The most important one was to activate the feature only at the end, Also, got mostly a clean run with checkpatch.pl. Sunil