| Age | Commit message (Collapse) | Author |
|---|
|
There are 3 command line options
To switch on the pass that marks functions for size optimisation use one of:
-fprofile-opt-cold-for-size (after inlining)
-fprofile-opt-cold-for-size-early (before inlining).
To make the pass mark functions that are neither hot or cold for size
optimisation but not minimum size optimisation use:
-fmark-neutral-cold
|
|
permits -fprofile-instr-generate to be used.
|
|
The generated MS manglings differ between 32- and 64-bit, and the test only
expects the latter. See also the commit email thread.
> Thanks to Cameron DaCamara at Microsoft for letting us know what their
> chosen mangling is here!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345380 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit r345370, as it uncovered even more issues in
tests with partial/inconsistent path normalization:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/13562
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/886
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20994
In particular, these tests seem to have failed:
Clang :: CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll
Clang :: CodeGen/thinlto-multi-module.ll
Clang :: Driver/cuda-external-tools.cu
Clang :: Driver/cuda-options.cu
Clang :: Driver/hip-toolchain-no-rdc.hip
Clang :: Driver/hip-toolchain-rdc.hip
Clang :: Driver/openmp-offload-gpu.c
At least the Driver tests could potentially be fixed by extending
the path normalization to even more places, but the issues with the
CodeGen tests are still unknown.
In addition, a number of other tests seem to have been broken in
other clang dependent tools such as clang-tidy and clangd.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345372 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
reported here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911561
clang-format-7 -style="{BreakBeforeBraces: Stroustrup}" wasn't doing
the same as the doc
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53520
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345371 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
libtool inspects the output of $CC -v to detect what object files and
libraries are linked in by default. When clang is built as a native
windows executable, all paths are formatted with backslashes, and
the backslashes cause each argument to be enclosed in quotes. The
backslashes and quotes break further processing within libtool (which
is implemented in shell script, running in e.g. msys) pretty badly.
Between unix style pathes (that only work in tools that are linked
to the msys runtime, essentially the same as cygwin) and proper windows
style paths (with backslashes, that can easily break shell scripts
and msys environments), the best compromise is to use windows style
paths (starting with e.g. c:) but with forward slashes, which both
msys based tools, shell scripts and native windows executables can
cope with. This incidentally turns out to be the form of paths that
GCC prints out when run with -v on windows as well.
This change potentially makes the output from clang -v a bit more
inconsistent, but it is isn't necessarily very consistent to begin with.
Compared to the previous attempt in SVN r345004, this now does
the same transformation on more paths, hopefully on the right set
of paths so that all tests pass (previously some tests failed, where
path fragments that were required to be identical turned out to
use different path separators in different places). This now also
is done only for non-windows, or cygwin/mingw targets, to preserve
all backslashes for MSVC cases (where the paths can end up e.g. embedded
into PDB files. (The transformation function itself,
llvm::sys::path::convert_to_slash only has an effect when run on windows.)
Differential Revision: https://reviews.llvm.org/D53066
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345370 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This corrects the leader for the swift names. The encoding for 4.2 and
5.0 differ by a single bit on the second character and were swapped.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345360 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Adds support for -mno-stack-arg-probe and -mstack-probe-size.
(Not really happy copy-pasting code, but that's what we do for all the
other Windows targets.)
Differential Revision: https://reviews.llvm.org/D53617
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345354 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Generate the FP16FML intrinsics into arm_neon.h (AArch64 only for now).
Add two new type modifiers to NeonEmitter to handle the new prototypes.
Define __ARM_FEATURE_FP16FML when +fp16fml is enabled and guard the
intrinsics with the macro in arm_neon.h.
Based on a patch by Gao Yiling.
Differential Revision: https://reviews.llvm.org/D53633
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345344 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Nodes which have only one predecessor and only one successor can not
always be hidden, even if all states are the same.
An additional condition is needed: the predecessor may have only one successor.
This can be seen on this example:
```
A
/ \
B C
\ /
D
```
Nodes B and C can not be hidden even if all nodes in the graph have the
same state.
Differential Revision: https://reviews.llvm.org/D53735
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345341 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
constructors and operators
Differential Revision: https://reviews.llvm.org/D53660
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345340 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D53628
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345339 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, OSDynamicCast was modeled as an identity.
This is not correct: the output of OSDynamicCast may be zero even if the
input was not zero (if the class is not of desired type), and thus the
modeling led to false positives.
Instead, we are doing eager state split:
in one branch, the returned value is identical to the input parameter,
and in the other branch, the returned value is zero.
This patch required a substantial refactoring of canEval infrastructure,
as now it can return different function summaries, and not just true/false.
rdar://45497400
Differential Revision: https://reviews.llvm.org/D53624
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks to Cameron DaCamara at Microsoft for letting us know what their
chosen mangling is here!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345330 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Constructing a global std::map requires clang to generate a linear
amount of code to construct the initializer list if the elements are not
constexpr-constructible. std::vector is not constexpr-constructible, so
this code pattern was generating large amounts of code.
Also, because of PR38829, LLVM is pathologically slow on large basic
blocks, and this causes slow compilation. This works around the bug and
reduces code size.
SemaChecking.cpp -debug-info-kind=limited:
time objsize
before: 1m45.023s 9.8M
after: 0m25.205s 6.9M
So, a 42% obj size reduction and 3.2x speedup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345329 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This doesn't appear to matter for deserialization purposes, because we
always know what kind of entity (declaration or statement/expression)
we're trying to load, but it makes the llvm-bcanalyzer output a lot less
mysterious.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345328 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change rejects the shadowing of a capture by a parameter in lambdas in C++17.
```
int main() {
int a;
auto f = [a](int a) { return a; };
}
```
results in:
```
main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity
auto f = [a](int a) { return a; };
^
main.cpp:3:13: note: variable a is explicitly captured here
auto f = [a](int a) { return a; };
^
```
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: lebedev.ri, erik.pilkington, cfe-commits
Differential Revision: https://reviews.llvm.org/D53595
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345308 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit b5d8d0de744d2c212bdb17d5c5fd4447dd14dbd2.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345306 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345303 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
storage class.
To be more in line with what GCC does, switch the condition to be based
on the Static Storage duration instead of the storage class.
Change-Id: I8e959d762433cda48855099353bf3c950b9d54b8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345302 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D53685
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345301 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: Goes along with D53721.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D53722
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345300 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the
resolver function directly to forward the call to the proper function.
This is not nearly as efficient as IFuncs of course, but is still quite
useful for large functions specifically developed for certain
processors.
This is unfortunately still limited to x86, since it depends on
__builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins.
The naming for the resolver/forwarding function for cpu-dispatch was
taken from ICC's implementation, which uses the unmodified name for this
(no mangling additions). This is possible, since cpu-dispatch uses '.A'
for the 'default' version.
In 'target' multiversioning, this function keeps the '.resolver'
extension in order to keep the default function keeping the default
mangling.
Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284
Differential Revision: https://reviews.llvm.org/D53586
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345298 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0).
Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload.
For example: https://godbolt.org/z/xXJELh
This patch fixes the confusion.
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53508
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345296 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Swift 5.0 has changed the name decoration for swift symbols, using a 'S' sigil
rather than 's' as in 4.2. Adopt the new convention.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345291 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This patch moves the last method in `Z3ConstraintManager` to `SMTConstraintManager`: `canReasonAbout()`.
The `canReasonAbout()` method checks if a given `SVal` can be encoded in SMT. I've added a new method to the SMT API to return true if a solver can encode floating-point arithmetics and it was enough to make `canReasonAbout()` solver independent.
As an annoying side-effect, `Z3ConstraintManager` is pretty empty now and only (1) creates the Z3 solver object by calling `CreateZ3Solver()` and (2) instantiates `SMTConstraintManager`. Maybe we can get rid of this class altogether in the future: a `CreateSMTConstraintManager()` method that does (1) and (2) and returns the constraint manager object?
Reviewers: george.karpenkov, NoQ
Reviewed By: george.karpenkov
Subscribers: mehdi_amini, xazax.hun, szepet, a.sidorin, dexonsmith, Szelethus, donat.nagy, dkrupp
Differential Revision: https://reviews.llvm.org/D53694
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345284 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Getting an `APSInt` from the model always returned an unsigned integer because of the unused parameter.
This was not breaking any test case because no code relies on the actual value of the integer returned here, but rather it is only used to check if a symbol has more than one solution in `getSymVal`.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus, donat.nagy, dkrupp
Differential Revision: https://reviews.llvm.org/D53637
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345283 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
According to the OpenMP standard, In a task generating construct, if no
default clause is present, a variable for which the data-sharing
attribute is not determined by the rules above is firstprivatized.
Compiler tries to implement this, but if the variable is not directly
used in the task context, this variable may not be firstprivatized.
Patch fixes this problem.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345277 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Add support for -mbranch-protection=<type>[+<type>]* where
- <type> ::= [standard, none, bti, pac-ret[+b-key,+leaf]*]
- The protection emits relevant function attributes
- sign-return-address=<scope>
- sign-return-address-key=<key>
- branch-protection
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345273 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345267 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MicrosoftExt allows explicit constructor calls. Prevent lookup of constructor name unless the name has explicit scope.
This avoids a compile-time crash due to confusing a member access for a constructor name.
Test case included. All tests pass.
Differential Revision: https://reviews.llvm.org/D53441
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345258 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
string parameter
Summary:
Currently clang-format breaks before the next parameter after multiline parameters (also recursively for the parent expressions of multiline parameters). However, it fails to do so for formatted multiline raw string literals:
```
$ cat test.cc
// Examples
// Regular multiline tokens
int x = f(R"(multi
line)", 2);
}
int y = g(h(R"(multi
line)"), 2);
// Formatted multiline tokens
int z = f(R"pb(multi: 1 #
line: 2)pb", 2);
int w = g(h(R"pb(multi: 1 #
line: 2)pb"), 2);
$ clang-format -style=google test.cc
// Examples
// Regular multiline tokens
int x = f(R"(multi
line)",
2);
}
int y = g(h(R"(multi
line)"),
2);
// Formatted multiline tokens
int z = f(R"pb(multi: 1 #
line: 2)pb", 2);
int w = g(h(R"pb(multi: 1 #
line: 2)pb"), 2);
```
This patch addresses this inconsistency by forcing breaking after multiline formatted raw string literals. This requires a little tweak to the indentation chosen for the contents of a formatted raw string literal: in case when that's a parameter and not the last one, the indentation is based off of the uniform indentation of all of the parameters.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52448
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345242 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
value is 0.
The X86 backend will need to see the attribute to make decisions. If it isn't present the backend will have to assume large vectors may be present.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345237 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
There is a small difference in the scope flags for C89 versus the other C/C++
dialects. This change ensures that the -Wcomma warning won't be duplicated or
issued in the wrong location. Also, the test case is refactored into C and C++
parts, with the C++ parts guarded by a #ifdef to allow the test to run in both
modes.
https://bugs.llvm.org/show_bug.cgi?id=32370
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345228 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit 6f47cdd51341344c0e32630e19e72c94cd25f34e.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345225 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add a new driver level flag `-fcf-runtime-abi=` that allows one to specify the
runtime ABI for CoreFoundation. This controls the language interoperability.
In particular, this is relevant for generating the CFConstantString classes
(primarily through the `__builtin___CFStringMakeConstantString` builtin) which
construct a reference to the "CFObject"'s `isa` field. This type differs
between swift 4.1 and 4.2+.
Valid values for the new option include:
- objc [default behaviour] - enable ObjectiveC interoperability
- swift-4.1 - enable interoperability with swift 4.1
- swift-4.2 - enable interoperability with swift 4.2
- swift-5.0 - enable interoperability with swift 5.0
- swift [alias] - target the latest swift ABI
Furthermore, swift 4.2+ changed the layout for the CFString when building
CoreFoundation *without* ObjectiveC interoperability. In such a case, a field
was added to the CFObject base type changing it from: <{ const int*, int }> to
<{ uintptr_t, uintptr_t, uint64_t }>.
In swift 5.0, the CFString type will be further adjusted to change the length
from a uint32_t on everything but BE LP64 targets to uint64_t.
Note that the default behaviour for clang remains unchanged and the new layout
must be explicitly opted into via `-fcf-runtime-abi=swift*`.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345222 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'ignore-non-existent-contents' stopped working after r342232 in a way
that the actual attribute value isn't used and it works as if it is
always `true`.
Common use case for VFS iteration is iterating through files in umbrella
directories for modules. Ability to detect if some VFS entries point to
non-existing files is nice but non-critical. Instead of adding back
support for `'ignore-non-existent-contents': false` I am removing the
attribute, because such scenario isn't used widely enough and stricter
checks don't provide enough value to justify the maintenance.
rdar://problem/45176119
Reviewers: bruno
Reviewed By: bruno
Subscribers: hiraditya, dexonsmith, sammccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D53228
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
When -faligned-allocation is specified in C++03 libc++ defines std::align_val_t as an unscoped enumeration type (because Clang didn't provide scoped enumerations as an extension until 8.0).
Unfortunately Clang confuses the `align_val_t` overloads of delete with the sized deallocation overloads which aren't enabled. This caused Clang to call the aligned deallocation function as if it were the sized deallocation overload.
For example: https://godbolt.org/z/xXJELh
This patch fixes the confusion.
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53508
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345211 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Subscribers: jholewinski, cfe-commits
Differential Revision: https://reviews.llvm.org/D53558
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345198 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
+ add required tests
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345181 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function
Summary:
For the following code:
```
int i;
#pragma omp taskloop
for (i = 0; i < 100; ++i)
{}
#pragma omp taskloop nogroup
for (i = 0; i < 100; ++i)
{}
```
Clang emits the following LLVM IR:
```
...
call void @__kmpc_taskgroup(%struct.ident_t* @0, i32 %0)
%2 = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* @0, i32 %0, i32 1, i64 80, i64 8, i32 (i32, i8*)* bitcast (i32 (i32, %struct.kmp_task_t_with_privates*)* @.omp_task_entry. to i32 (i32, i8*)*))
...
call void @__kmpc_taskloop(%struct.ident_t* @0, i32 %0, i8* %2, i32 1, i64* %8, i64* %9, i64 %13, i32 0, i32 0, i64 0, i8* null)
call void @__kmpc_end_taskgroup(%struct.ident_t* @0, i32 %0)
...
%15 = call i8* @__kmpc_omp_task_alloc(%struct.ident_t* @0, i32 %0, i32 1, i64 80, i64 8, i32 (i32, i8*)* bitcast (i32 (i32, %struct.kmp_task_t_with_privates.1*)* @.omp_task_entry..2 to i32 (i32, i8*)*))
...
call void @__kmpc_taskloop(%struct.ident_t* @0, i32 %0, i8* %15, i32 1, i64* %21, i64* %22, i64 %26, i32 0, i32 0, i64 0, i8* null)
```
The first set of instructions corresponds to the first taskloop construct. It is important to note that the implicit taskgroup region associated with the taskloop construct has been materialized in our IR: the `__kmpc_taskloop` occurs inside a taskgroup region. Note also that this taskgroup region does not exist in our second taskloop because we are using the `nogroup` clause.
The issue here is the 4th argument of the kmpc_taskloop call, starting from the end, is always a zero. Checking the LLVM OpenMP RT implementation, we see that this argument corresponds to the nogroup parameter:
```
void __kmpc_taskloop(ident_t *loc, int gtid, kmp_task_t *task, int if_val,
kmp_uint64 *lb, kmp_uint64 *ub, kmp_int64 st, int nogroup,
int sched, kmp_uint64 grainsize, void *task_dup);
```
So basically we always tell to the RT to do another taskgroup region. For the first taskloop, this means that we create two taskgroup regions. For the second example, it means that despite the fact we had a nogroup clause we are going to have a taskgroup region, so we unnecessary wait until all descendant tasks have been executed.
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D53636
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345180 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The compiler is crashing if we trying to post-capture the fields
implicitly captured inside of the task constructs. Seems, this kind of
processing is not supported and such fields should not be
firstprivatized.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345177 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These tests don't run unless the aarch64 target is registered and my testing had been on an x86 only build directory.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345176 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This will allow other generators of LLVM IR to use the auto-vectorizer
without having to change that flag.
Note: on its own, this patch will disable auto-vectorization on Hexagon
in all cases, regardless of the -fvectorize flag. There is a companion
LLVM patch that together with this one forms an NFC for clang users.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345170 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
return types
This is a continuation of my patches to inform the X86 backend about what the largest IR types are in the function so that we can restrict the backend type legalizer to prevent 512-bit vectors on SKX when -mprefer-vector-width=256 is specified if no explicit 512 bit vectors were specified by the user.
This patch updates the vector width based on the argument and return types of the current function and from the types of any functions it calls. This is intended to make sure the backend type legalizer doesn't disturb any types that are required for ABI.
Differential Revision: https://reviews.llvm.org/D52441
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345168 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Extract the reference to the ASTContext and Triple and use them throughout the
function. This is simply a cosmetic cleanup while in the area. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345160 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Unindent the body of the function by inverting check at the top. This is in
preparation for supporting CFString's new ABI with swift. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345159 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary: New name suggestions were being used in places where existing names should have been used, this patch tries to fix some of those situations.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D53191
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345152 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These declarations somehow survived a cleanup that combined them with the target
multiversioning functions. This patch removes them as they are no
longer necessary or used.
Change-Id: I318286401ace63bef1aa48018dabb25be0117ca0
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@345145 91177308-0d34-0410-b5e6-96231b3b80d8
|
