[PATCH 1/7] SMS remove dependence on doloop: Use loop induction variable analysis in SMS pass

Hi, SMS transformation would change the kernel loop iteration count. To do this, SMS pass will find the register contain loop count and generate the instructions to adjust loop count. Currently, SMS will try to find count_reg by recognizing doloop_end pattern which means if the target didn't defi

[PATCH 3/7] SMS remove dependence on doloop: Update loop-versioning for the loop with step != 1

Hi, To avoid the loop with loop_count < stage_count execute the SMS version loop, SMS will try to get loop iteration count. If the loop iteration count can't get by compile time, SMS will do loop-versioning which will generate original loop and SMS version loop with runtime checking code. With do

[PATCH 2/7] SMS remove dependence on doloop: Use get_simple_loop_desc to get loop iteration count

Hi, The loop after SMS transformation would at least execute stage_count times (due to the duplication in prolog/epilog). To avoid the loop with loop_count < stage_count execute the sms version loop, SMS will try to get loop iteration count. Currently, SMS would get iteration count by finding the

[PATCH 5/7] SMS remove dependence on doloop: update generate_prolog_epilog for the case without doloop pass

Hi, SMS transformation will generate prolog/epilog which are part of the duplication of the instructions in the loop. Doloop optimization will generate a new register(count_reg) to hold iteration count. Therefore, there will no count_reg reference in the loop (except increment/decrement and compa

[PATCH 6/7] SMS remove dependence on doloop: skip the loop if the loop size too small

Hi, SMS loop versioning will generate extra condition code. If SMS could not find enough overlapping in the loop, it may drop performance. Adding parameter PARAM_SMS_LOOP_MIN_SIZE with default value 8 to skip small loops which may not find enough overlapping instructions. Thanks, Shiva 0006-s

[PATCH 7/7] SMS remove dependence on doloop: To identify read/write register as loop induction variable

Hi, We use loop induction variable analysis to find count_reg. Without doloop optimization, count_reg might be a READ_WRITE_REG. E.g. while (reg < 0x200) { MEM [++reg:SI] = 5} READ_WRITE_REG won't identify as loop induction variable and SMS will skip the loop. We modify loop-iv.c to identify th

[PATCH 4/7] SMS remove dependence on doloop: update kernel loop iteration adjustment instruction generation

Hi, SMS transformation would change kernel loop iteration count as new_loop_count = ori_loop_count - stage_count. With doloop optimization, loop_count will hold in count_reg in loop entry. The loop count adjustment instruction could generate as count_reg = count_reg - stage_count before en

[PATCH 0/7] SMS remove dependence on doloop

Hi, The patch try to remove SMS dependency on doloop pass. With the patch, backend don't have to define doloop_end pattern or activate doloop optimization for SMS pass. According the review comment from Bernd https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01960.html I rewrite some comments and sp

Re: [PATCH][SMS] SMS use loop induction variable analysis instead of depending on doloop optimization

Hi, Bernd Thanks for the review. > > You might want to split it up if there are several logically independent > pieces. I can't quite make sense of it all, and I'm not too familiar with SMS > anyway, so the following is not a complete review, just a selection of issues > I observed. Ok, I hav

Ping: Re: OpenMP offloading to NVPTX: backend patches

Hi! Now that we are in stage1, I'd like to ping this patch series from Alexander. As those are (mostly) patches against the nvptx backend, they need to be reviewed by NVPTX maintainers, and are needed before the corresponding generic OpenMP offloading and libgomp changes are reviewed. On Wed, Ap

Re: [SPARC] Support for --with-{cpu,tune}-{32,64} in sparc*-* targets

> This patch adds support for the --with-{cpu,tune}-{32,64} configure > options to sparc*-* targets. This allows to separately select cpus and > tune options for -m32 and -m64 modes in multilib compilers. SPARC/Linux is not the only SPARC target though. :-) > Tested in sparc64-*-* and sparcv9-*-

<    1   2