Currently, we have no front-end type for ppc_fp128 type in IR. PowerPC
target generates ppc_fp128 type from long double now, but there's option
(-mabi=(ieee|ibm)longdouble) to control it and we're going to do
transition from IBM extended double-double ppc_fp128 to IEEE fp128 in
the future.
This patch adds type __ibm128 which always represents ppc_fp128 in IR,
as what GCC did for that type. Without this type in Clang, compilation
will fail if compiling against future version of libstdcxx (which uses
__ibm128 in headers).
Although all operations in backend for __ibm128 is done by software,
only PowerPC enables support for it.
There's something not implemented in this commit, which can be done in
future ones:
- Literal suffix for __ibm128 type. w/W is suitable as GCC documented.
- __attribute__((mode(IF))) should be for __ibm128.
- Complex __ibm128 type.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D93377
Before: _Atomic(uint64_t) * a;
After: _Atomic(uint64_t) *a;
This treats _Atomic the same as the the TypenameMacros and decltype. It
also allows some cleanup by removing checks whether the token before a
paren is kw_decltype and instead checking for TT_TypeDeclarationParen.
While touching this code also extend the decltype test cases to also check
for typeof() and _Atomic(T).
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D86959
The underlying ABI forces FormatToken to have a lot of padding.
Currently (on x86-64 linux) `sizeof(FormatToken) == 288`. After this patch
`sizeof(FormatToken) == 232`.
No functional changes.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D84306
Summary:
This patch upstreams support for a new storage only bfloat16 C type.
This type is used to implement primitive support for bfloat16 data, in
line with the Bfloat16 extension of the Armv8.6-a architecture, as
detailed here:
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
The bfloat type, and its properties are specified in the Arm Architecture
Reference Manual:
https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
In detail this patch:
- introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type.
This is part of a patch series, starting with command-line and Bfloat16
assembly support. The subsequent patches will upstream intrinsics
support for BFloat16, followed by Matrix Multiplication and the
remaining Virtualization features of the armv8.6-a architecture.
The following people contributed to this patch:
- Luke Cheeseman
- Momchil Velikov
- Alexandros Lamprineas
- Luke Geeson
- Simon Tatham
- Ties Stuij
Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli
Reviewed By: SjoerdMeijer
Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76077
This enables us to intercept changes to the token type via setType(), which
is a precondition for being able to use multi-pass formatting for macro
arguments.
Differential Revision: https://reviews.llvm.org/D67405
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)
This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.
llvm-svn: 331244
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
llvm-svn: 312794
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
llvm-svn: 312781
Members that are themselves wrapped in fake parentheses would lead to
AvoidBinPacking be set on the wrong ParenState.
After:
vector<int> aaaa = {
aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaa.aaaaaaa,
aaaaaa.aaaaaaa,
aaaaaa.aaaaaaa,
aaaaaa.aaaaaaa,
};
Before we were falling back to bin-packing these.
llvm-svn: 290259
We still want to try in linewrap within single elements of a 1-column
list.
After:
Type *Params[] = {PointerType::getUnqual(FunctionType::get(
Builder.getVoidTy(), Builder.getInt8PtrTy(), false)),
Builder.getInt8PtrTy(),
Builder.getInt32Ty(),
LongType,
LongType,
LongType};
Before:
No line break in the first element, so column limit violation.
llvm-svn: 290090
column limit.
Single-column layout basically means that we format the list with one
element per line. Not doing that when there is a column limit violation
doesn't change the fact that there is an item that doesn't fit within
the column limit.
Before (with a column limit of 30):
std::vector<int> a = {
aaaaaaaa, aaaaaaaa,
aaaaaaaa, aaaaaaaa,
aaaaaaaaaa, aaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaa};
After:
std::vector<int> a = {
aaaaaaaa,
aaaaaaaa,
aaaaaaaa,
aaaaaaaa,
aaaaaaaaaa,
aaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaa};
(and previously we would have formatted like "After" it wasn't for the one
item that is too long)
llvm-svn: 290084
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
initializers. For now, only use it for 20 items or more. Otherwise,
clang-format formats these one-per-line and thus increases the vertical
code size a lot.
llvm-svn: 256246
Summary:
If this option is set, clang-format will always insert a line wrap, e.g.
before the first parameter of a function call unless all parameters fit
on the same line. This obviates the need to make a decision on the
alignment itself.
Use this style for Google's JavaScript style and add some minor tweaks
to correctly handle nested blocks etc. with it. Don't use this option
for for/while loops.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D14104
llvm-svn: 251405
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
To implement this nicely, add a function that merges two sets of
replacements that are meant to be done in sequence. This functionality
will also be useful for other applications, e.g. formatting the result
of clang-tidy fixes.
llvm-svn: 248367
instead of BinPackParameters. Braced lists are used as constructor
calls in many places and so the bin-packing should follow what is done
for other calls and not what is done for function declarations.
llvm-svn: 238184
comments. At some point, we might to want to a layout with a different
number of columns instead, but at the moment, this causes more
confusion than it's worth.
llvm-svn: 237427
Specifically, calculate the deviation between the shortest and longest
element (which is used to prevent excessive whitespace) per column, not
overall. This automatically handles the corner cases of a single column
and a single row so that the actualy implementation becomes simpler.
Before:
vector<int> x = {1,
aaaaaaaaaaaaaaaaaaaaaa,
2,
bbbbbbbbbbbbbbbbbbbbbb,
3,
cccccccccccccccccccccc};
After:
vector<int> x = {1, aaaaaaaaaaaaaaaaaaaaaa,
2, bbbbbbbbbbbbbbbbbbbbbb,
3, cccccccccccccccccccccc};
llvm-svn: 236992
In particular:
* If the difference between the longest and shortest element, we copped
out of column format completely. Now, we instead allow to arrange
these in a single column, essentially enforcing a one-per-line format.
* Allow column layout even if there are braced lists. Especially, if
there are many short lists, this can be beneficial. The bad case,
where there is a long nested init list is usually caught as we now
limit the length difference of the longest and shortest element.
llvm-svn: 236851
This patch only considers the difference between the length of the
shortest and longest element, but we might want to look at other
features (token count, etc.) in future.
Before:
std::vector<MyValues> aaaaaaaaaaaaaaaaaaa{
aaaaaaa, aaaaaaaaaa,
aaaaa, aaaaaaaaaaaaaaa,
aaa, aaaaaaaaaa,
a, aaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaa,
aaaaaaa, a};
After:
std::vector<MyValues> aaaaaaaaaaaaaaaaaaa{
aaaaaaa, aaaaaaaaaa, aaaaa, aaaaaaaaaaaaaaa, aaa, aaaaaaaaaa, a,
aaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaa, aaaaaaa, a};
llvm-svn: 218111
With BinPackParameters=false and Cpp11BracedListStyle=true (i.e. mostly
for Chromium):
Before:
const Aaaaaa aaaaa = {aaaaa, bbbbb, ccccc, ddddd, eeeee, ffffff,
ggggg, hhhhhh, iiiiii, jjjjjj, kkkkkk};
After:
const Aaaaaa aaaaa = {aaaaa,
bbbbb,
ccccc,
ddddd,
eeeee,
ffffff,
ggggg,
hhhhhh,
iiiiii,
jjjjjj,
kkkkkk};
This fixes llvm.org/PR19359. I am not sure we'll want this in all cases
in the long run, but I'll guess we'll get feedback on that.
llvm-svn: 206458
- Format a braced list with one element per line if it has nested
braced lists.
- Use a column layout only when the list has 6+ elements (instead of the
current 4+ elements).
llvm-svn: 198869
Marek Kurdej