And here are the patches...

Mark



On Tue, Sep 2, 2014 at 10:42 AM, Mark Heffernan <[email protected]> wrote:

> Sorry, forgot about this :-(  Here's the patched to release_35 which
> removes reference to unroll-related pragmas and the respective metadata as
> discussed earlier in the thread.  These are doc-only (*.rst) patches.  OK?
>
> Bill, can these be merged to the release branch?  Background: 3.5 was cut
> in the middle of a number of changes to support the unroll pragma.  Since
> the cut, the metadata and unroll pragma syntax have changed and a couple of
> small bug fixes went in.  These doc patches remove any reference to the
> unroll pragma and metadata so we don't have to carry forward support for
> the older syntax.  Also, this avoid publicizing the unroll pragmas which at
> the time of the cut had a couple of unpatched bugs.
>
> Thanks!
> Mark
>
>
> On Mon, Aug 25, 2014 at 2:39 PM, Hal Finkel <[email protected]> wrote:
>
>> ----- Original Message -----
>> > From: "Mark Heffernan" <[email protected]>
>> > To: "Hal Finkel" <[email protected]>
>> > Cc: "Eric Christopher" <[email protected]>, "cfe-commits" <
>> [email protected]>, [email protected],
>> > "Aaron Ballman" <[email protected]>
>> > Sent: Thursday, August 21, 2014 6:22:16 PM
>> > Subject: Re: release_35 patches for unroll pragma
>> >
>> >
>> >
>> >
>> > On Tue, Aug 19, 2014 at 5:42 PM, Hal Finkel < [email protected] >
>> > wrote:
>> >
>> >
>> >
>> >
>> > Unfortunately, I was on vacation that week, and I'm still playing
>> > catch-up on my e-mail...
>> >
>> > At this point I think it is too late to pull in these kinds of
>> > changes, but, if we didn't previously, we should add auto-upgrade
>> > support for the renamed metadata.
>> >
>> >
>> >
>> > Recently got back from vacation myself... Earlier in the thread there
>> > was the suggestion of removing mention of the unroll pragma and
>> > metadata from the 3.5 docs because support for it is incomplete. I
>> > agree and I'll send out a patch for this. Would it still be
>> > necessary to add the auto-upgrade support since the unroll pragma
>> > and associated metadata would not be officially supported?
>>
>> If it is not documented nor officially supported, probably not.
>>
>>  -Hal
>>
>> >
>> >
>> > Thanks,
>> > Mark
>> >
>> >
>> > -Hal
>> >
>> > >
>> > > -eric
>> > >
>> >
>> > --
>> > Hal Finkel
>> > Assistant Computational Scientist
>> > Leadership Computing Facility
>> > Argonne National Laboratory
>> >
>> >
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>
>
Index: docs/LangRef.rst
===================================================================
--- docs/LangRef.rst	(revision 216912)
+++ docs/LangRef.rst	(working copy)
@@ -2902,15 +2902,15 @@
 
 The loop identifier metadata can be used to specify additional
 per-loop metadata. Any operands after the first operand can be treated
-as user-defined metadata. For example the ``llvm.loop.unroll.count``
-suggests an unroll factor to the loop unroller:
+as user-defined metadata. For example the ``llvm.loop.interleave.count``
+suggests an interleave factor to the loop interleaver:
 
 .. code-block:: llvm
 
       br i1 %exitcond, label %._crit_edge, label %.lr.ph, !llvm.loop !0
     ...
     !0 = metadata !{ metadata !0, metadata !1 }
-    !1 = metadata !{ metadata !"llvm.loop.unroll.count", i32 4 }
+    !1 = metadata !{ metadata !"llvm.loop.interleave.count", i32 4 }
 
 '``llvm.loop.vectorize``' and '``llvm.loop.interleave``'
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -2970,52 +2970,6 @@
 0 or if the loop does not have this metadata the width will be
 determined automatically.
 
-'``llvm.loop.unroll``'
-^^^^^^^^^^^^^^^^^^^^^^
-
-Metadata prefixed with ``llvm.loop.unroll`` are loop unrolling
-optimization hints such as the unroll factor. ``llvm.loop.unroll``
-metadata should be used in conjunction with ``llvm.loop`` loop
-identification metadata. The ``llvm.loop.unroll`` metadata are only
-optimization hints and the unrolling will only be performed if the
-optimizer believes it is safe to do so.
-
-'``llvm.loop.unroll.enable``' Metadata
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This metadata either disables loop unrolling or suggests that the loop
-be unrolled fully. The first operand is the string
-``llvm.loop.unroll.enable`` and the second operand is a bit.  If the
-bit operand value is 0 loop unrolling is disabled. A value of 1
-indicates that the loop should be fully unrolled. For example:
-
-.. code-block:: llvm
-
-   !0 = metadata !{ metadata !"llvm.loop.unroll.enable", i1 0 }
-   !1 = metadata !{ metadata !"llvm.loop.unroll.enable", i1 1 }
-
-'``llvm.loop.unroll.count``' Metadata
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This metadata suggests an unroll factor to the loop unroller. The
-first operand is the string ``llvm.loop.unroll.count`` and the second
-operand is a positive integer specifying the unroll factor. For
-example:
-
-.. code-block:: llvm
-
-   !0 = metadata !{ metadata !"llvm.loop.unroll.count", i32 4 }
-
-If the trip count of the loop is less than the unroll count the loop
-will be partially unrolled.
-
-If a loop has both a ``llvm.loop.unroll.enable`` metadata and
-``llvm.loop.unroll.count`` metadata the behavior depends upon the
-value of the ``llvm.loop.unroll.enable`` operand.  If the value is 0,
-the loop will not be unrolled.  If the value is 1, the loop will be
-unrolled with a factor determined by the ``llvm.loop.unroll.count``
-operand effectively ignoring the ``llvm.loop.unroll.enable`` metadata.
-
 '``llvm.mem``'
 ^^^^^^^^^^^^^^^
 
Index: docs/LanguageExtensions.rst
===================================================================
--- docs/LanguageExtensions.rst	(revision 216912)
+++ docs/LanguageExtensions.rst	(working copy)
@@ -1787,12 +1787,8 @@
 
 The ``#pragma clang loop`` directive is used to specify hints for optimizing the
 subsequent for, while, do-while, or c++11 range-based for loop. The directive
-provides options for vectorization, interleaving, and unrolling. Loop hints can
-be specified before any loop and will be ignored if the optimization is not safe
-to apply.
-
-Vectorization and Interleaving
-------------------------------
+provides options for vectorization and interleaving. Loop hints can be specified
+before any loop and will be ignored if the optimization is not safe to apply.
 
 A vectorized loop performs multiple iterations of the original loop
 in parallel using vector instructions. The instruction set of the target
@@ -1835,46 +1831,6 @@
 Specifying a width/count of 1 disables the optimization, and is equivalent to
 ``vectorize(disable)`` or ``interleave(disable)``.
 
-Loop Unrolling
---------------
-
-Unrolling a loop reduces the loop control overhead and exposes more
-opportunities for ILP. Loops can be fully or partially unrolled. Full unrolling
-eliminates the loop and replaces it with an enumerated sequence of loop
-iterations. Full unrolling is only possible if the loop trip count is known at
-compile time. Partial unrolling replicates the loop body within the loop and
-reduces the trip count.
-
-If ``unroll(enable)`` is specified the unroller will attempt to fully unroll the
-loop if the trip count is known at compile time. If the loop count is not known
-or the fully unrolled code size is greater than the limit specified by the
-`-pragma-unroll-threshold` command line option the loop will be partially
-unrolled subject to the same limit.
-
-.. code-block:: c++
-
-  #pragma clang loop unroll(enable)
-  for(...) {
-    ...
-  }
-
-The unroll count can be specified explicitly with ``unroll_count(_value_)`` where
-_value_ is a positive integer. If this value is greater than the trip count the
-loop will be fully unrolled. Otherwise the loop is partially unrolled subject
-to the `-pragma-unroll-threshold` limit.
-
-.. code-block:: c++
-
-  #pragma clang loop unroll_count(8)
-  for(...) {
-    ...
-  }
-
-Unrolling of a loop can be prevented by specifying ``unroll(disable)``.
-
-Additional Information
-----------------------
-
 For convenience multiple loop hints can be specified on a single line.
 
 .. code-block:: c++
Index: docs/ReleaseNotes.rst
===================================================================
--- docs/ReleaseNotes.rst	(revision 216912)
+++ docs/ReleaseNotes.rst	(working copy)
@@ -184,17 +184,9 @@
 -----------------------
 
 Loop optimization hints can be specified using the new `#pragma clang loop`
-directive just prior to the desired loop. The directive allows vectorization,
-interleaving, and unrolling to be enabled or disabled. Vector width as well
-as interleave and unrolling count can be manually specified.  See
-:ref:`langext-pragma-loop` for details.
-
-Clang now supports the `#pragma unroll` directive to specify loop unrolling
-optimization hints.  Placed just prior to the desired loop, `#pragma unroll`
-directs the loop unroller to attempt to fully unroll the loop.  The pragma may
-also be specified with a positive integer parameter indicating the desired
-unroll count: `#pragma unroll _value_`.  The unroll count parameter can be
-optionally enclosed in parentheses.
+directive just prior to the desired loop. The directive allows vectorization and
+interleaving to be enabled or disabled. Vector width as well as interleave count
+can be manually specified.  See :ref:`langext-pragma-loop` for details.
 
 C Language Changes in Clang
 ---------------------------
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to