similar to: [LLVMdev] Disable loop unroll pass

Hi shuxin, Promote while-loop to do-loop is the job of loop induction recognized, not this transformation. The scalar transform for hwloop in optimizer is for that it is a trouble to discriminate trip counting code with the real production code stuff and do the elimination in cg, we have to write customized code to handle this general stuff in ervey targets. So, we take the help from optimizer

Hi Shuxin, On 23/11/2012 00:17, Shuxin Yang wrote: > Hi, Gang: > > I don't want to discuss Open64 internal in LLVM mailing list. Let us > only focus on the design per se. > As your this mail and your previous mail combined give me a impression > that : > > The only reason you introduce the specific operator for HW loop in > Scalar Opt simply because >

Hi, Ivan: Sorry for deviating the topic a bit. As I told you before I'm a LLVM newbie, I cannot give you conclusive answer if the proposed interface is ok or not. My personal opinion on these two interface is summarized bellow: - hasZeroCostLoop() pro: it is clearly state the HW support. con: Having zero cost loop doesn't imply the benefit HW loop could achieve.

Hi, Gang: I don't want to discuss Open64 internal in LLVM mailing list. Let us only focus on the design per se. As your this mail and your previous mail combined give me a impression that : The only reason you introduce the specific operator for HW loop in Scalar Opt simply because you have hard time in figure out the trip count in CodeGen. This might be true for Open64's

Hi, Gang: I remember there were different voices when you check-in the code. I agree with them although I didn't reply your mail in open64's mailing list. In the transformation you illustrate, it involves two operations: 1) promote WHILE-loop into DO-loop (i.e noncountable loop to countable loop) 2) get rid of trip-count dec/inc and compare. 1) is irrelevant to HW loop.

I am the designer for open64 hwloop structure, but I am not a student. Hope the following helps: To transform a loop into hwloop, we need the help from optimizer. For example, while(k3>=10){ sum+=k1; k3 --; } into the form: zdl_loop(k3-9) { sum+=k1; } So, we introduce a new ZDLBR whirl(open64 optimizer intermediate) operator, which represents the loop in whirl as:

Hi Shuxin, Eli, On 22/11/2012 03:19, Shuxin Yang wrote: > Hi, Ivan: > > My $0.02. hasZeroCostLooping() disabling unrolling dose not seem > to be > appropriate for other architectures, at least the one I worked before. I appreciate your feed-back. Could you give an example where building a hw loop is not appropriate for your target? > > You mentioned: >

On Wed, Jul 17, 2013 at 1:06 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > > On 7/17/13 12:35 PM, Diego Novillo wrote: >> >> On Fri, Jul 12, 2013 at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> >> wrote: >> >>> 3. How to parallelize post-IPO stage >>> ==================================== >>> >>> From 5k'

On 7/17/13 12:35 PM, Diego Novillo wrote: > On Fri, Jul 12, 2013 at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> 3. How to parallelize post-IPO stage >> ==================================== >> >> From 5k' high, the concept is very simple, just to >> step 1).divide the merged IR into small pieces, >> step 2).and compile

On 7/31/13 4:30 PM, Tobias Grosser wrote: > On 07/30/2013 09:44 PM, Chris Lattner wrote: >> >> On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: >> >>> The pro for running LICM early is that it may move big redundant >>> stuff out of loop nest. You never know >>> how big it is. In case you are lucky , you can move

On 7/31/13 4:47 PM, Shuxin Yang wrote: > > On 7/31/13 4:30 PM, Tobias Grosser wrote: >> On 07/30/2013 09:44 PM, Chris Lattner wrote: >>> >>> On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> >>> wrote: >>> >>>> The pro for running LICM early is that it may move big redundant >>>> stuff out of loop

On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > The pro for running LICM early is that it may move big redundant stuff out of loop nest. You never know > how big it is. In case you are lucky , you can move lot of stuff out of > loop, the loop may become much smaller and hence enable lots of downstream optimizations. This sound > to be a big win

Hi, Ivan: My $0.02. hasZeroCostLooping() disabling unrolling dose not seem to be appropriate for other architectures, at least the one I worked before. You mentioned: >Currently, we cannot detect them because the loop unroller is >unrolling them before entering into the codegen. Looking at its implementation, >it. Could you please articulate why CG fail to recognize it?

On 07/30/2013 09:44 PM, Chris Lattner wrote: > > On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> The pro for running LICM early is that it may move big redundant stuff out of loop nest. You never know >> how big it is. In case you are lucky , you can move lot of stuff out of >> loop, the loop may become much smaller and hence

Hi Shuxin, > Is it legal to delete empty infinite loop like this : "while(1) {}"? > It is interesting that both llvm and gcc keep the loop, however Open64 delete it. this is an endless source of discussion. I suggest you read the GCC and LLVM mailing list archives if you want to find out more about it. Ciao, Duncan. > If it is safe to delete this loop, it would be

On Wed, Nov 14, 2012 at 03:32:53PM +0800, 陳韋任 (Wei-Ren Chen) wrote: > On Tue, Nov 13, 2012 at 11:23:02PM -0800, Shuxin Yang wrote: > > Hi, All: > > > > Is it legal to delete empty infinite loop like this : "while(1) {}"? > > It is interesting that both llvm and gcc keep the loop, however Open64 > > delete it. > > I think it's illegal

On Tue, Nov 13, 2012 at 11:23:02PM -0800, Shuxin Yang wrote: > Hi, All: > > Is it legal to delete empty infinite loop like this : "while(1) {}"? > It is interesting that both llvm and gcc keep the loop, however Open64 > delete it. I think it's illegal to delete such infinite loop, perhapes you should file a bug report to open64. That's my 2 cents.

Following loop (in asm) is often seen in embedded programs. It is used to delay for certain amount of time. If it were not written in asm, compiler would blindly delete the entire loop. How can compiler know such DCE betray program intention? for (i = 0; i < N; i++) { nop; nop; nop } I guess in the gray area, if programmer do not want compiler do something he doesn't expect, he/she

On Fri, Jul 12, 2013 at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > 3. How to parallelize post-IPO stage > ==================================== > > From 5k' high, the concept is very simple, just to > step 1).divide the merged IR into small pieces, > step 2).and compile each of this pieces independendly. > step 3) the objects of each piece

Hi, All: Is it legal to delete empty infinite loop like this : "while(1) {}"? It is interesting that both llvm and gcc keep the loop, however Open64 delete it. If it is safe to delete this loop, it would be lot easier to delete non-obvious dead loop like following as compiler doesn't need to prove if the loop in question is infinite or not. Currently llvm is not able to