[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Fwd: Register Pressure in Instruction Level Parallelism
From:       Kenneth Zadeck <zadeck () naturalbridge ! com>
Date:       2009-06-29 0:30:31
Message-ID: 4A480B27.2040704 () naturalbridge ! com
[Download RAW message or body]

David Edelsohn wrote:
> ---------- Forwarded message ----------
> From: Albert Cohen <Albert.Cohen@inria.fr>
> Date: Sun, Jun 28, 2009 at 6:25 PM
> Subject: Re: Register Pressure in Instruction Level Parallelism
> To: Dave Korn <dave.korn.cygwin@googlemail.com>
> Cc: reply@meinersbur.de, gcc@gcc.gnu.org, Sid Touati
> <Sid.Touati@inria.fr>, Frederic Brault <frederic.brault@inria.fr>
>
>
> Hi all,
>
> I'm convinced that saturation and sufficiency based approaches are the
> future of register pressure management.
>
> [Please keep my colleague Sid Touati in CC of this thread, until he
> registers to the list.]
>
> Unfortunately, the state of the art (more recent that the thesis
> referenced in the original email, see Touati's web page) is limited to
> basic block and software-pipelining scopes, and limited to scheduling.
>
> Compared to the tasks currently managed by reload, it certainly misses
> a whole bunch of instruction selection and immediate operand/address
> mode corner case problems (depending on the target). It also misses
> global scheduling, but extended BB scheduling is not very hard to
> approximate, as well as superblock scheduling.
>
>   
> I'm not at all a knowledgeable person to tell you what to do in the
> case of GCC, but for sure saturation/sufficiency-based approches are
> not sufficient to kill the dragon.
>
> However, I will strongly advise anybody (= Kenny Zadeck) looking at a
> fresh SSA-based backend design to consider such an approach to avoid
> messing up with pressure-aware-* where * is any backend pass that
> bears a risk of blowing up register pressure.
>
>   
I am considering such a design and i did, late last week to go public
with my project.  I am now working to put up a project in the public
spaces.  I would very much like the help of anyone who is interested in
working in this area to consider working on it in gcc.


kenny
> If you interested in collaboration on the topic, we are about to start
> extending those approaches to general control-flow, and implementing
> it in a production compiler (not GCC, but a free one, and not LLVM
> either).
>
> Albert
>
>
> Dave Korn wrote:
>   
>> Michael Kruse wrote:
>>
>>     
>>> So, now my questions: How much do you think could this could improve
>>> compiled code speed? Would the current GCC/YARA benefit from such an
>>> optimization pass at all? What are the chances that this could get into
>>> the main GCC tree if it shows up to be an improvement?
>>>       
>>  One of the major problems in gcc is the intertangling of instruction
>> selection with register allocation and spill generation.  If these could be
>> separated it would almost certainly generate better code and be welcomed with
>> open arms!
>>
>>     
>>> I'd prefer to implement this for the gcc, but my advisor wants me to do
>>> it for the university's own compiler. Therefore I could also need
>>> arguments why to do it for the GCC.
>>>       
>>  Because destroying reload(*) would be an incalculable public service and
>> your name will be remembered in history as the one who slew the dragon? ;-)
>>
>>    cheers,
>>      DaveK
>>     

[prev in list] [next in list] [prev in thread] [next in thread]