Append new attributes to the end of an AttributeList.

Recommit of r335084 after revert in r335516.

... instead of prepending it at the beginning (the original behavior
since implemented in r122535

Append new attributes to the end of an AttributeList.

Recommit of r335084 after revert in r335516.

... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.

The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse order, and therefore printed in the wrong order in
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.

The change unfortunately has some secondary effect, especially on
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attributes' order was changed instead.

This unfortunately causes some 'previous occurrence here' hints to be
textually after the main marker. This typically happens when attributes
are merged, but are incompatible to each other. Interchanging the role
of the the main and note SourceLocation will also cause the case where
two different declaration's attributes (in contrast to multiple
attributes of the same declaration) are merged to be reverse. There is
no easy fix because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway.

Differential Revision: https://reviews.llvm.org/D48100

llvm-svn: 338800

show more ...

Revert "Append new attributes to the end of an AttributeList."

This reverts commit r335084 as requested by David Jones and
Eric Christopher because of differences of emitted warnings.

llvm-svn: 335

Revert "Append new attributes to the end of an AttributeList."

This reverts commit r335084 as requested by David Jones and
Eric Christopher because of differences of emitted warnings.

llvm-svn: 335516

show more ...

Append new attributes to the end of an AttributeList.

... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList i

Append new attributes to the end of an AttributeList.

... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.

The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse, and therefore printed in the wrong order by
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.

The change unfortunately has some secondary effects, especially for
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attribute's order was changed instead.

It also causes some 'previous occurrence here' hints to be textually
after the main marker. This typically happens when attributes are
merged, but are incompatible. Interchanging the role of the the main
and note SourceLocation will also cause the case where two different
declaration's attributes (in contrast to multiple attributes of the
same declaration) are merged to be reversed. There is no easy fix
because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway, which often is on the same line.

Differential Revision: https://reviews.llvm.org/D48100

llvm-svn: 335084

show more ...

[OpenMP] Fix trailing space when printing pragmas, by Joel. E. Denny

Summary:
-ast-print prints omp pragmas with a trailing space. While this
behavior is likely of little concern to most users, sur

[OpenMP] Fix trailing space when printing pragmas, by Joel. E. Denny

Summary:
-ast-print prints omp pragmas with a trailing space. While this
behavior is likely of little concern to most users, surely it's
unintentional, and it's annoying for some source-level work I'm
pursuing. This patch focuses on omp pragmas, but it also fixes
init_seg and loop hint pragmas because they share implementation.

The testing strategy here is to add usually just one '{{$}}' per
relevant -ast-print test file. This seems to achieve good code
coverage. However, this strategy is probably easy to forget as the
tests evolve. That's probably fine as this fix is far from critical.
The main goal of the testing is to aid the initial review.

This patch also adds a fixme for "#pragma unroll", which prints as
"#pragma unroll (enable)", which is invalid syntax.

Reviewers: ABataev

Reviewed By: ABataev

Subscribers: guansong, cfe-commits

Differential Revision: https://reviews.llvm.org/D43204

llvm-svn: 325145

show more ...

Add loop pragma for Loop Distribution

Summary:
This is similar to other loop pragmas like 'vectorize'. Currently it
only has state values: distribute(enable) and distribute(disable). When
one of t

Add loop pragma for Loop Distribution

Summary:
This is similar to other loop pragmas like 'vectorize'. Currently it
only has state values: distribute(enable) and distribute(disable). When
one of these is specified the corresponding loop metadata is generated:

!{!"llvm.loop.distribute.enable", i1 true/false}

As a result, loop distribution will be attempted on the loop even if
Loop Distribution in not enabled globally. Analogously, with 'disable'
distribution can be turned off for an individual loop even when the pass
is otherwise enabled.

There are some slight differences compared to the existing loop pragmas.

1. There is no 'assume_safety' variant which makes its handling slightly
different from 'vectorize'/'interleave'.

2. Unlike the existing loop pragmas, it does not have a corresponding
numeric pragma like 'vectorize' -> 'vectorize_width'. So for the
consistency checks in CheckForIncompatibleAttributes we don't need to
check it against other pragmas. We just need to check for duplicates of
the same pragma.

Reviewers: rsmith, dexonsmith, aaron.ballman

Subscribers: bob.wilson, cfe-commits, hfinkel

Differential Revision: http://reviews.llvm.org/D19403

llvm-svn: 272656

show more ...

Allow constant expressions in pragma loop hints.

Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such a

Allow constant expressions in pragma loop hints.

Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1).

Reviewed by Richard Smith

llvm-svn: 219589

show more ...

Add support for #pragma nounroll.

llvm-svn: 213885

In unroll pragma syntax and loop hint metadata, change "enable" forms to a new form using the string "full".

llvm-svn: 213771

Add support for '#pragma unroll'.

llvm-svn: 213574

Add loop unroll pragma support

http://reviews.llvm.org/D4089

Patch by Mark Heffernan.

llvm-svn: 210667

*Really* fix DOS newlines introduced in r210330

r210369 didn't quite catch all of them.

llvm-svn: 210593

Adding a new #pragma for the vectorize and interleave optimization hints.

Patch thanks to Tyler Nowicki!

llvm-svn: 210330