This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Fix PR19401: always completely peel loops


> From: Richard Guenther <richard.guenther@gmail.com>
> On Thu, 13 Jan 2005 13:51:27 -0500, Paul Schlie <schlie@comcast.net> wrote:
>>> Richard Guenther writes:
>>> This minimal patch unconditionally enables complete loop peeling
>>> at the tree level.
>> 
>> Isn't it rather presumptuous to assume that such a thing is universally
>> beneficial to all targets?
>> 
>> (as would expect it to predominantly result in bloated code for smaller
>> lightly pipelined targets, with little if any tangible benefit; unless I
>> misunderstand?)
> 
> Sure.  I guess maybe we should do this for the C++ frontend only - it
> is not only for loop optimization itself, but also would expose more
> variables to scalarization (if only complete loop peeling was run
> before scalarization).  I should probably file another bug wrt the
> lack of scalarization for
> 
> int a[4];
> for (int i=0; i<4; ++i)
>   a[i] = i;
> 
> (or better a more useful example where scalarization has a benefit)

Wouldn't a reasonably simple and small bound on the peeling at -O3 still
allow such small loops to be unwound, while not letting those substantially
larger and/or less-dense from getting out of hand?

Something along the line of: relax the code size growth from 0 to some small
number of instructions larger than the original (like 8-16 for example);
which should allow small dense loops to be fully unwound, while effectively
limiting loops (which correspondingly benefit less from peeling) from being
unwound as aggressively if at all.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]