> The middle-end, testsuite and boilerplate changes in the FEs are ok.
Thanks. But it turns out that the Ada compiler needs a way to convey a pragma
unroll without explicit unrolling factor, because otherwise the RTL unroller
will happily try to unroll some loops USHRT_MAX times...
Tested on x
On Wed, Nov 22, 2017 at 11:46 AM, Eric Botcazou wrote:
> Hi,
>
> this is a revised version of:
> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01452.html
>
> with the following changes:
> 1. integration of Bernhard's patch for the Fortran front-end,
> 2. Sandra's fix for the documentation,
>
On 11/21/2017 03:18 AM, Eric Botcazou wrote:
First of all, the structuring in this section is screwed up. The
discussion and examples for the previous item (#pragma ivdep) should be
moved inside the @table so that you don't have to introduce another
@table here, just insert another entry into th
Hi,
this is a revised version of:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01452.html
with the following changes:
1. integration of Bernhard's patch for the Fortran front-end,
2. Sandra's fix for the documentation,
3. minor tweaks to the C and C++ front-end,
4. change at the GIMPLE lev
> The documentation for the directive is missing indeed. We can fix this
> during stage3.
Someone who speaks Fortran will have to write it down...
> Currently the directive works on the whole function (see
> gfc_cfun_has_unroll()) and instructs the loop-optimizers to run on
> that function.
gfc_
> First of all, the structuring in this section is screwed up. The
> discussion and examples for the previous item (#pragma ivdep) should be
> moved inside the @table so that you don't have to introduce another
> @table here, just insert another entry into the existing one.
That's also the case f
On 20 November 2017 at 15:45, Steve Kargl
wrote:
> On Mon, Nov 20, 2017 at 12:57:47PM +0100, Bernhard Reutner-Fischer wrote:
>> On 20 November 2017 at 12:26, Eric Botcazou wrote:
>> >> If anybody finds the time to push the corresponding Fortran changes then
>> >> I'd
>> >> be grateful. I won't h
On 11/17/2017 03:23 AM, Eric Botcazou wrote:
Index: doc/extend.texi
===
--- doc/extend.texi (revision 254797)
+++ doc/extend.texi (working copy)
@@ -22376,6 +22376,18 @@ void ignore_vec_dep (int *a, int k, int
@}
@end smal
On Mon, Nov 20, 2017 at 12:57:47PM +0100, Bernhard Reutner-Fischer wrote:
> On 20 November 2017 at 12:26, Eric Botcazou wrote:
> >> If anybody finds the time to push the corresponding Fortran changes then
> >> I'd
> >> be grateful. I won't have time for this until end of stage 1...
> >>
> >> http
On 20 November 2017 at 12:26, Eric Botcazou wrote:
>> If anybody finds the time to push the corresponding Fortran changes then I'd
>> be grateful. I won't have time for this until end of stage 1...
>>
>> https://gcc.gnu.org/ml/fortran/2015-02/msg00014.html
>
> OK, I'm going to merge it in the main
> Looking at the middle-end changes. The change to ANNOTATE_EXPR to three
> operands is approved also for existing frontends (just in case you
> don't get review).
> Found the missing possibility of an argument limiting myself...
I see. ;-)
> Your changes to the RTL unrolling pass as far as I se
> If anybody finds the time to push the corresponding Fortran changes then I'd
> be grateful. I won't have time for this until end of stage 1...
>
> https://gcc.gnu.org/ml/fortran/2015-02/msg00014.html
OK, I'm going to merge it in the main patch.
--
Eric Botcazou
On 17 November 2017 14:31:45 CET, Richard Biener
wrote:
>On Fri, Nov 17, 2017 at 11:23 AM, Eric Botcazou
>wrote:
>> Hi,
>>
>> this is a cleaned up and updated revision of Mike's latest posted
>patch
>> implementing #pragma GCC unroll in the C and C++ compilers. To be
>honest,
>> we're not so mu
On Fri, Nov 17, 2017 at 11:23 AM, Eric Botcazou wrote:
> Hi,
>
> this is a cleaned up and updated revision of Mike's latest posted patch
> implementing #pragma GCC unroll in the C and C++ compilers. To be honest,
> we're not so much interested in the front-end bits as in the middle-end bits,
> be
Hi,
this is a cleaned up and updated revision of Mike's latest posted patch
implementing #pragma GCC unroll in the C and C++ compilers. To be honest,
we're not so much interested in the front-end bits as in the middle-end bits,
because the latter would at last make the Ada version of the pragm
15 matches
Mail list logo