Implement stack arrays even for unknown sizes

Richard Guenther richard.guenther@gmail.com
Wed Apr 13 11:13:00 GMT 2011


On Wed, Apr 13, 2011 at 12:38 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 13, 2011 at 11:42 AM, Paul Richard Thomas
> <paul.richard.thomas@gmail.com> wrote:
>> Dear Dominique,
>>
>>> I think it is the automatic array in the subroutine trisolve. Note that the
>>> speedup is rather 27->19s and may be darwin specific (slow malloc).
>>
>> I saw a speed-up of similar order on FC9/x86_64.
>>
>> I strongly doubt that it is anything to do with the automatic array -
>> if it is there is an error somewhere, since none of the references to
>> trisolve need copy-in/copy-out.
>>
>>>
>>> Note also that -fstack-arrays prevents some optimizations on
>>> fatigue: 4.7->7s. This may be related to pr45810.
>>
>> Has PR45810 converged now?  If I have understood properly, a patch has
>> been devised that cures the problem and does not cause slow-downs
>> anywhere else?
>
> VLAs and malloc based arrays may behave differently with respect to alias
> analysis (I'd have to look at some examples).  All effects other than malloc
> overhead I would attribute to that.  That said, the general idea of the patch
> is sound and I see nothing wrong with it.  Both performance improvements
> and regressions are worth looking at - they hint at possible improvements
> in the middle-end parts of the compiler.

I have opened PR48590 for at least one issue that I see.  It has a very
simple patch which you might want to try ...

Richard.



More information about the Gcc-patches mailing list