| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The windows bots are failing due to a memory layout error. Temporarily disabling
while I investigate whether this can be worked around, or whether the test
should be disabled on Windows.
llvm-svn: 374500
|
|
|
|
|
|
|
|
| |
The original implementation failed to shift the immediate down.
This should fix some of the bot failures due to r374476.
llvm-svn: 374499
|
|
|
|
| |
llvm-svn: 374498
|
|
|
|
| |
llvm-svn: 374497
|
|
|
|
|
|
|
|
|
|
| |
parameter type.
We were both failing to decay the array type to a pointer and failing to
remove the top-level cv-qualifications. Fix this by decaying array
parameters even if the parameter type is dependent.
llvm-svn: 374496
|
|
|
|
| |
llvm-svn: 374495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The output directories for CMake's Xcode project generator are
specific to the configuration, and so looking in
CMAKE_LIBRARY_OUTPUT_DIRECTORY isn't going to work. Fortunately, CMake
already provides generator expressions to find the output of a given
target.
I call this "barely" building because the built framework isn't going
to respect the configuration; that is, I can't have both Debug and
RelWithDebInfo variants of ClangdXPC.framework at the same time like I
can with normal library or executable targets. To do that we'd have to
put the framework in a configuration-specific output directory or use
CMake's native support for frameworks instead.
https://reviews.llvm.org/D68846
llvm-svn: 374494
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intended usage is to measure relatively expensive operations. So the
cost of the statistic is negligible compared to the cost of a measured
operation and can be enabled all the time without impairing the
compilation time.
rdar://problem/55715134
Reviewers: dsanders, bogner, rtereshin
Reviewed By: dsanders
Subscribers: hiraditya, jkorous, dexonsmith, ributzka, cfe-commits, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68252
llvm-svn: 374490
|
|
|
|
|
|
| |
clss.
llvm-svn: 374488
|
|
|
|
|
|
|
|
|
|
| |
instructions in more situations.
If we don't have VLX we won't end up selecting a saturating
truncate for 256-bit or smaller vectors so we should just use
the pack lowering.
llvm-svn: 374487
|
|
|
|
|
|
|
|
|
| |
use a load for the large type and add the min-legal-vector-width attribute.
The attribute is needed to avoid zmm registers. Using memory
avoids argument splitting for large vectors.
llvm-svn: 374486
|
|
|
|
|
|
|
|
|
|
|
| |
file.
Reduces duplication and thereby reduces the risk that someone will
forget to update one of these places, as I did when adding
DefaultedDestructorIsConstexpr (though I've been unable to produce
a testcase for which that matters so far).
llvm-svn: 374484
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Makes the indent consistent to other part of the file.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68842
llvm-svn: 374483
|
|
|
|
| |
llvm-svn: 374482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we insert them from function pass some analysis may be missing or invalid.
Fixes PR42877.
Reviewers: eugenis, leonardchan
Reviewed By: leonardchan
Subscribers: hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D68832
llvm-svn: 374481
|
|
|
|
| |
llvm-svn: 374480
|
|
|
|
| |
llvm-svn: 374479
|
|
|
|
| |
llvm-svn: 374478
|
|
|
|
|
|
|
|
|
| |
This implementation has support for all relocation types except TLV.
Compact unwind sections are not yet supported, so exceptions/unwinding will not
work.
llvm-svn: 374476
|
|
|
|
|
|
| |
'named_data' should be the first symbol in the data section.
llvm-svn: 374475
|
|
|
|
|
|
|
|
|
|
| |
Subscribers: mehdi_amini, jtony, xbolva00, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66840
llvm-svn: 374474
|
|
|
|
|
|
| |
that the test runs on Windows
llvm-svn: 374473
|
|
|
|
| |
llvm-svn: 374472
|
|
|
|
|
|
|
|
|
|
| |
When simplifying a Phi to the unique value found incoming, check that
there wasn't a Phi already created to break a cycle. If so, remove it.
Resolves PR43541.
Some additional nits included.
llvm-svn: 374471
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- So far, we only recognize the host compilation with offloading and
skip the offloading part.
Reviewers: tra, yaxunl
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68660
llvm-svn: 374470
|
|
|
|
| |
llvm-svn: 374468
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D68823
llvm-svn: 374467
|
|
|
|
|
|
| |
an out-of-lifetime object.
llvm-svn: 374465
|
|
|
|
|
|
| |
Forgot to integrate this little change in previous commit
llvm-svn: 374463
|
|
|
|
|
|
| |
This test is disabled upstream and therefore this went unnoticed.
llvm-svn: 374462
|
|
|
|
|
|
|
| |
Add the Python extension to the configuration files in the API directory
to match the other test suites.
llvm-svn: 374461
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When handling the packus pattern for i32->i8 we do a two step
process using a packss to i16 followed by a packus to i8. If the
final i8 step is a type with less than 64-bits the packus step
will return SDValue(), but the i32->i16 step might have succeeded.
This leaves the nodes from the middle step dangling.
Guard against this by pre-checking that the number of elements is
at least 8 before doing the middle step.
With that check in place this should mean the only other
case the middle step itself can fail is when SSE2 is disabled. So
add an early SSE2 check then just assert that neither the middle
or final step ever fail.
llvm-svn: 374460
|
|
|
|
| |
llvm-svn: 374459
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In GISel we have both G_CONSTANT and G_FCONSTANT, but because
in GISel we don't really have a concept of Float vs Int value
the only difference between the two is where the data originates
from.
What both G_CONSTANT and G_FCONSTANT return is just a bag of bits
with the constant representation in it.
By making getConstantVRegVal() return G_FCONSTANTs bit representation
as well we allow ConstantFold and other things to operate with
G_FCONSTANT.
Adding tests that show ConstantFolding to work on mixed G_CONSTANT
and G_FCONSTANT sources.
Differential Revision: https://reviews.llvm.org/D68739
llvm-svn: 374458
|
|
|
|
|
|
| |
vector conversions disabled.
llvm-svn: 374457
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test fails on Windows, with
error: 'warning' diagnostics expected but not seen:
File builtin-assume-aligned.c Line 62: requested alignment
must be 268435456 bytes or smaller; assumption ignored
error: 'warning' diagnostics seen but not expected:
File builtin-assume-aligned.c Line 62: requested alignment
must be 8192 bytes or smaller; assumption ignored
llvm-svn: 374456
|
|
|
|
|
|
|
|
| |
It was missing an undef flag.
Differential Revision: https://reviews.llvm.org/D68813
llvm-svn: 374455
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch improves the handling of pointer offset in GEP expressions where
one argument is the base pointer. isPointerOffset() is being used by memcpyopt
where current code synthesizes consecutive 32 bytes stores to one store and
two memset intrinsic calls. With this patch, we convert the stores to one
memset intrinsic.
Differential Revision: https://reviews.llvm.org/D67989
llvm-svn: 374454
|
|
|
|
|
|
| |
Also, refactor check in `LibCallSimplifier::optimizeLog()`.
llvm-svn: 374453
|
|
|
|
|
|
|
|
|
|
|
| |
This change is purely mechanical. I will do further cleanups of
parameter usages.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D68830
llvm-svn: 374452
|
|
|
|
|
|
| |
r374262 left out the Makefile changes needed to cross compile this test.
llvm-svn: 374451
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code to handle __builtin_assume_aligned was allowing larger values, but
would convert this to unsigned along the way. This patch removes the
EmitAssumeAligned overloads that take unsigned to do away with this
problem.
Additionally, it adds a warning that values greater than 1 <<29 are
ignored by LLVM.
Differential Revision: https://reviews.llvm.org/D68824
llvm-svn: 374450
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed that compiling on Windows with -fno-ms-compatibility had the
side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and
a number of other macros for GCC compatibility. This is undesirable and
causes Chromium to do things like mix __attribute__ and __declspec,
which doesn't work. We should have a positive language option to enable
GCC compatibility features so that we can experiment with
-fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be
that option.
My issue aside, users have, for a long time, reported that __GNUC__
doesn't match their expectations in one way or another. We have
encouraged users to migrate code away from this macro, but new code
continues to be written assuming a GCC-only environment. There's really
nothing we can do to stop that. By adding this flag, we can allow them
to choose their own adventure with __GNUC__.
This overlaps a bit with the "GNUMode" language option from -std=gnu*.
The gnu language mode tends to enable non-conforming behaviors that we'd
rather not enable by default, but the we want to set things like
__GXX_RTTI__ by default, so I've kept these separate.
Helps address PR42817
Reviewed By: hans, nickdesaulniers, MaskRay
Differential Revision: https://reviews.llvm.org/D68055
llvm-svn: 374449
|
|
|
|
|
|
| |
A fix for r373993.
llvm-svn: 374448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Whenever we get the previous definition, the assumption is that the
recursion starts ina reachable block.
If the recursion starts in an unreachable block, we may recurse
indefinitely. Handle this case by returning LoE if the block is
unreachable.
Resolves PR43426.
Reviewers: george.burgess.iv
Subscribers: Prazek, sanjoy.google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68809
llvm-svn: 374447
|
|
|
|
|
|
|
|
|
|
| |
Move the default implementations of cache and prefetch queries to
TargetTransformInfoImplBase and delete them from NoTIIImpl. This brings these
interfaces in line with how other TTI interfaces work.
Differential Revision: https://reviews.llvm.org/D68804
llvm-svn: 374446
|
|
|
|
| |
llvm-svn: 374445
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After rLLDB365761, and with `LLVM_ENABLE_ABI_BREAKING_CHECKS` enabled,
launching any process on FreeBSD crashes lldb with:
```
Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed).
```
This is because `m_operation_thread` and `m_monitor_thread` were wrapped
in `llvm::Expected<>`, but this requires the objects to be correctly
initialized before accessing them.
To fix the crashes, use `llvm::Optional<>` for the members (as indicated
by labath), and use local variables to store the return values of
`LaunchThread` and `StartMonitoringChildProcess`. Then, only assign to
the member variables after checking if the return values indicated
success.
Reviewers: devnexen, emaste, MaskRay, mgorny
Reviewed By: devnexen
Subscribers: jfb, labath, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D68723
llvm-svn: 374444
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D68736
llvm-svn: 374443
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A common pattern in Windows is to have all your precompiled headers
use an object named stdafx.obj. If you've got a project with many
different static libs, you might use a separate PCH for each one of
these.
During the final link step, a file from A might reference the PCH
object from A, but it will have the same name (stdafx.obj) as any
other PCH from another project. The only difference will be the
path. For example, A might be A/stdafx.obj while B is B/stdafx.obj.
The existing algorithm checks only the filename that was passed on
the command line (or stored in archive), but this is insufficient in
the case where relative paths are used, because depending on the
command line object file / library order, it might find the wrong
PCH object first resulting in a signature mismatch.
The fix here is to simply check whether the absolute path of the
PCH object (which is stored in the input obj file for the file that
references the PCH) *ends with* the full relative path of whatever
is specified on the command line (or is in the archive).
Differential Revision: https://reviews.llvm.org/D66431
llvm-svn: 374442
|