Re: Allocating some Loop allocno in memory

2015-01-11 Thread Richard Biener
On January 11, 2015 5:25:23 AM CET, Ajit Kumar Agarwal 
 wrote:
>
>I was thinking of some of the opportunities with respect to reducing
>spills inside the Loop. If the Live range(allocno) 
>spans through the Loop and Live out at the exit of the Loop and there
>are no references or not being touched upon
>inside the Loop, assign the allocno to the memory. This increase the
>chances of getting the register for other allocno 
>which spans through the Loop and have reference inside the Loop if the
>interference graph is not colorable.
>
>Since allocno don't have references inside the Loop there won't be any
>load instructions with respect to restore inside
>the loops. There will be a store  instruction with respect to spill
>which will be outside the Loop. This will reduce the
>conflicting edges of some of the allocno increasing the chances of
>making colorable of the Interference graph and 
>reduces the spills and restore inside the Loop.
>
>This heuristics looks reasonable. This heuristics goes side by side
>with the Live range splitting across the Loop boundary.
>On top of this heuristics, after the Live range splitting across the
>Loop boundary there interference graph is not colorable
>then we can assign some of the  splitted live ranges in the memory
>giving chances of registers  for the Live ranges(allocno) 
>that spans the Loop and have reference inside the Loop.
>
>We can change the cost of allocno in memory based on the above
>heuristics and take the above factor into consideration 
>for the cost calculation.
>
>Thoughts Please?

How can this result in better allocations if you only ever spill at life-range 
split points? The life-range covering the loop should already be assigned to 
memory if required.

Richard.

>Thanks & Regards
>Ajit




RE: Allocating some Loop allocno in memory

2015-01-11 Thread Ajit Kumar Agarwal


-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com] 
Sent: Sunday, January 11, 2015 8:05 PM
To: Ajit Kumar Agarwal; vmaka...@redhat.com; l...@redhat.com; gcc@gcc.gnu.org
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: Allocating some Loop allocno in memory

On January 11, 2015 5:25:23 AM CET, Ajit Kumar Agarwal 
 wrote:
>
>I was thinking of some of the opportunities with respect to reducing 
>spills inside the Loop. If the Live range(allocno) spans through the 
>Loop and Live out at the exit of the Loop and there are no references 
>or not being touched upon inside the Loop, assign the allocno to the 
>memory. This increase the chances of getting the register for other 
>allocno which spans through the Loop and have reference inside the Loop 
>if the interference graph is not colorable.
>
>Since allocno don't have references inside the Loop there won't be any 
>load instructions with respect to restore inside the loops. There will 
>be a store  instruction with respect to spill which will be outside the 
>Loop. This will reduce the conflicting edges of some of the allocno 
>increasing the chances of making colorable of the Interference graph 
>and reduces the spills and restore inside the Loop.
>
>This heuristics looks reasonable. This heuristics goes side by side 
>with the Live range splitting across the Loop boundary.
>On top of this heuristics, after the Live range splitting across the 
>Loop boundary there interference graph is not colorable then we can 
>assign some of the  splitted live ranges in the memory giving chances 
>of registers  for the Live ranges(allocno) that spans the Loop and have 
>reference inside the Loop.
>
>We can change the cost of allocno in memory based on the above 
>heuristics and take the above factor into consideration for the cost 
>calculation.
>
>Thoughts Please?

>>How can this result in better allocations if you only ever spill at 
>>life-range split points? The life-range covering the loop should already be 
>>assigned to >>memory if required.

If the live range covering the loop assigned to memory, and there are 
references inside the Loops  then there are chances
of spills inside the loop which degrades the performance.  If live range 
covering the loops and there are no references inside
the Loop, then assigning to memory make reasonable as there are no references. 
Since there are no references or not
touched inside the Loop, there won't be load instruction to restore which are 
required if there are any references. The store
which requires for the def of the Live range will be outside the Loops. This 
helps in not degrading the performances as there
are no load and store required for spill and restore inside the Loops.

The above heuristics can also be accompanied with heuristics of the number of 
use points in the Live range. Considering both
 the heuristics will lead to better allocation if ever spill at the live range 
split points and there are chances of getting colorable
 the Interference graph without degrading the performance. Also if the Live 
range is splitted at the Loop boundary then the spill
 at the split points of loop boundary and registers is assigned to this live 
range will make it reasonable if there are no references 
inside the Loops.

Thanks & Regards
Ajit

Richard.

>Thanks & Regards
>Ajit




gcc-5-20150111 is now available

2015-01-11 Thread gccadmin
Snapshot gcc-5-20150111 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150111/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 219440

You'll find:

 gcc-5-20150111.tar.bz2   Complete GCC

  MD5=02daa06e68852c95d98541b04c19ee68
  SHA1=f88469921446e61dcab81a807db3ca93982ef8d1

Diffs from 5-20150104 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


Undeliverable message

2015-01-11 Thread Postmaster
This message was created automatically by mail delivery software. Your email 
message was not delivered to the intended recipients because malware was 
detected.

--- Additional Information ---

Subject: warning
Sender: gcc@gcc.gnu.org

Time received: 1/12/2015 6:59:56 AM
Message ID: <8ce092b79c2a4871b296648ce4367...@am1ffo11fd041.protection.gbl>
Detections found: 
attachment.doc.scr   Win32/Netsky.C@mm