| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the CARRY ops instead.
Summary:
As per title. This cleanup some technical debt.
Depends on D33374
Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33390
llvm-svn: 304435
|
| |
|
|
|
|
|
| |
Now it is as early as it can go: just before synchronize. We now have
to move synchronize earlier too.
llvm-svn: 304434
|
| |
|
|
|
|
|
| |
I don't have a testcase in mind, but there is no reason to have the
linker script out of sync during a -r link.
llvm-svn: 304433
|
| |
|
|
|
|
| |
Also needed to move clearOutputSections earlier.
llvm-svn: 304420
|
| |
|
|
|
|
| |
This is needed to move clearOutputSections earlier.
llvm-svn: 304419
|
| |
|
|
|
|
|
| |
Partial revert of r301938 which is making it harder
to split patches up.
llvm-svn: 304418
|
| |
|
|
|
|
| |
These are only integer operations.
llvm-svn: 304417
|
| |
|
|
| |
llvm-svn: 304416
|
| |
|
|
| |
llvm-svn: 304415
|
| |
|
|
| |
llvm-svn: 304414
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Without using a fixup in this case, BL will be used instead of BLX to
call internal ARM functions from Thumb functions.
Reviewers: rafael, t.p.northover, peter.smith, kristof.beyls
Reviewed By: peter.smith
Subscribers: srhines, echristo, aemerson, rengolin, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33436
llvm-svn: 304413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Solaris-specific implementation for llvm::sys::fs::is_local_impl.
FStype pattern matching might be a bit unreliable, but at least it fixes the build failure.
Reviewers: mgorny, nlopes, llvm-commits, krytarowski
Reviewed By: krytarowski
Subscribers: voskresensky.vladimir, krytarowski
Differential Revision: https://reviews.llvm.org/D33695
llvm-svn: 304412
|
| |
|
|
|
|
| |
300 was reached in r304190, 400 should be enough for a while.
llvm-svn: 304411
|
| |
|
|
|
| |
Suggested-by: Michael Kruse <llvm@meinersbur.de>
llvm-svn: 304410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a problem uncovered by stage2 testing. ADDCARRY end up being generated on target that do not support it.
The patch that introduced the problem has other patches layed on top of it, so we want to fix the issue rather than revert it to avoid creating a lor of churn.
A regression test will be added shortly, but this is committed as this in order to get the build back to green promptly.
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33770
llvm-svn: 304409
|
| |
|
|
|
|
| |
Make the test less restrictive to allow directory layout used in our test setup.
llvm-svn: 304408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the original patch by Davide, but I've adjusted the API exposed
to just be different entry points rather than exposing more state
parameters. I've factored all the common logic out so that we don't have
any duplicate pipelines, we just stitch them together in different ways.
I think this makes the build easier to reason about and understand.
This adds a direct method for getting the module simplification pipeline
as well as a method to get the optimization pipeline. While not my
express goal, this seems nice and gives a good place comment about the
restrictions that are imposed on them.
I did make some minor changes to the way the pipelines are structured
here, but hopefully not ones that are significant or controversial:
1) I sunk the PGO indirect call promotion to only be run when we have
PGO enabled (or as part of the special ThinLTO pipeline).
2) I made the extra GlobalOpt run in ThinLTO just happen all the time
and at a slightly more powerful place (before we remove available
externaly functions). This seems like general goodness and not a big
compile time sink, so it didn't make sense to *only* use it in
ThinLTO. Fewer differences in the pipeline makes everything simpler
IMO.
3) I hoisted the ThinLTO stop point pre-link above the the RPO function
attr inference. The RPO inference won't infer anything terribly
meaningful pre-link (recursiveness?) so it didn't make a lot of
sense. But if the placement of RPO inference starts to matter, we
should move it to the canonicalization phase anyways which seems like
a better place for it (and there is a FIXME to this effect!). But
that seemed a bridge too far for this patch.
If we ever need to parameterize these pipelines more heavily, we can
always sink the logic to helper functions with parameters to keep those
parameters out of the public API. But the changes above seemed minor
that we could possible get away without the parameters entirely.
I added support for parsing 'thinlto' and 'thinlto-pre-link' names in
pass pipelines to make it easy to test these routines and play with them
in larger pipelines. I also added a really basic manifest of passes test
that will show exactly how the pipelines behave and work as well as
making updates to them clear.
Lastly, this factoring does introduce a nesting layer of module pass
managers in the default pipeline. I don't think this is a big deal and
the flexibility of decoupling the pipelines seems easily worth it.
Differential Revision: https://reviews.llvm.org/D33540
llvm-svn: 304407
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add an early combine to match patterns such as:
(i16 bitcast (v16i1 x))
->
(i16 movmsk (v16i8 sext (v16i1 x)))
This combine needs to happen early enough before
type-legalization scalarizes the result of the setcc.
Reviewers: igorb, craig.topper, RKSimon
Subscribers: delena, llvm-commits
Differential Revision: https://reviews.llvm.org/D33311
llvm-svn: 304406
|
| |
|
|
|
|
|
| |
Only android and linux can have this function as far as I am aware, but
it seems cleaner to enable this code for all platforms.
llvm-svn: 304405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
usubo/setcccarry.
Summary:
This is a continuation of the work started in D29872 . Passing the carry down as a value rather than as a glue allows for further optimizations. Introducing setcccarry makes the use of addc/subc unecessary and we can start the removal process.
This patch only introduce the optimization strictly required to get the same level of optimization as was available before nothing more.
Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33374
llvm-svn: 304404
|
| |
|
|
|
|
| |
work.
llvm-svn: 304403
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This pattern is no very useful per se, but it exposes optimization for toehr patterns that wouldn't kick in otherwize. It's very common and worth optimizing for.
Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32756
llvm-svn: 304402
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This enables further transforms.
Depends on D32916
Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32925
llvm-svn: 304401
|
| |
|
|
|
|
|
|
|
|
| |
If the variable was a pointer, code was ignoring the change in the
pointee.
Discussed in
http://lists.llvm.org/pipermail/lldb-dev/2017-May/012435.html
llvm-svn: 304400
|
| |
|
|
|
|
|
|
| |
Recommit of r302781 with Vitaly Buka's fix for non zero terminated strings.
Differential Revision: https://reviews.llvm.org/D31457
llvm-svn: 304399
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A partial write is a write where the domain of the values written is a subset of
the execution domain of the parent statement containing the write. Originally,
we directly checked this subset relation whereas it is indeed only important
that the subset relation holds for the parameter values that are known to be
valid in the execution context of the scop. We update our check to avoid the
unnecessary introduction of partial writes in situations where the write appears
to be partial without context information, but where context information allows
us to understand that a full write can be generated.
This change fixes (hides) a recent regression introduced in r303517, which broke
our AOSP builds. The part that is correctly fixed in this change is that we do
not any more unnecessarily generate a partial write. This is good performance
wise and, as we currently do not yet explicitly introduce partial writes in the
default configuration, this also hides possible bugs in the partial writes
implementation. The crashes that we have originally seen were caused by such
a bug, where partial writes were incorrectly generated in region statements. An
additional patch in a subsequent commit is needed to address this problem.
Reported-by: Reported-by: Eli Friedman <efriedma@codeaurora.org>
Differential Revision: https://reviews.llvm.org/D33759
llvm-svn: 304398
|
| |
|
|
| |
llvm-svn: 304397
|
| |
|
|
| |
llvm-svn: 304396
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We can emit vtable definition having inline function
if they are all emitted.
Reviewers: rjmccall, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33437
llvm-svn: 304394
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is PR33243. R_GOTONLY_PC_FROM_END was not in a list of link time constant
expressions and that was a result of confusiing messages like PR shows:
/usr/bin/ld.lld: error: /usr/lib/go/src/runtime/alg.go:47:
can't create dynamic relocation R_386_GOTPC against local symbol in readonly segment defined in /tmp/nice/go-link-597453838/go.o
Though in reality we just should not have try to create a dynamic relocation for this case at all.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D33717
llvm-svn: 304393
|
| |
|
|
|
|
|
|
| |
This is PR33239, previously we segfault on given testcase.
Differential revision: https://reviews.llvm.org/D33713
llvm-svn: 304392
|
| |
|
|
| |
llvm-svn: 304391
|
| |
|
|
|
|
|
| |
As discussed in
http://lists.llvm.org/pipermail/llvm-dev/2017-May/113525.html
llvm-svn: 304390
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rationale: OpenCL kernels are called via an explicit runtime API
with arguments set with clSetKernelArg(), not as normal sub-functions.
Return SPIR_KERNEL by default as the kernel calling convention to ensure
the fingerprint is fixed such way that each OpenCL argument gets one
matching argument in the produced kernel function argument list to enable
feasible implementation of clSetKernelArg() with aggregates etc. In case
we would use the default C calling conv here, clSetKernelArg() might
break depending on the target-specific conventions; different targets
might split structs passed as values to multiple function arguments etc.
https://reviews.llvm.org/D33639
llvm-svn: 304389
|
| |
|
|
|
|
|
|
| |
Record::setName(StringRef). Leave just the versions that take an Init.
They weren't used often enough to justify having two different interfaces. Push the responsiblity of creating a StringInit up to the caller.
llvm-svn: 304388
|
| |
|
|
|
|
|
|
| |
never execute.
It tried to detect 9 letters (the length of anonymous) followed by a period. But anonymous classes start with "anonymous_" rather than "anonymous." these days.
llvm-svn: 304387
|
| |
|
|
|
|
| |
places. NFC
llvm-svn: 304386
|
| |
|
|
| |
llvm-svn: 304385
|
| |
|
|
| |
llvm-svn: 304384
|
| |
|
|
| |
llvm-svn: 304383
|
| |
|
|
| |
llvm-svn: 304382
|
| |
|
|
|
|
|
|
|
|
|
| |
We were looking up sections by name during expression evaluation. By
keeping track of forward declarations we can do the lookup during
script parsing.
Doing the lookup earlier will be more efficient when assignAddresses
is run twice and removes two uses of OutputSections.
llvm-svn: 304381
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allocas
Summary:
Coroutine related test that used to trigger broken IR prior to r304335.
```
%x = alloca i32, align 4
store i32* %x, i32** %tmp.exprcleanup, align 4 ; <===== HERE
%ref.tmp3 = alloca %struct.A, align 1
%agg.tmp5 = alloca %"struct.std::experimental::coroutines_v1::coroutine_handle.0", align 4
%tmp.exprcleanup = alloca i32*, align 4
%allocapt = bitcast i32 undef to i32
store i32 %0, i32* %.addr, align 4
```
Fixed with r304335
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33750
llvm-svn: 304380
|
| |
|
|
|
|
| |
using the SB API's not the lldb_private API's.
llvm-svn: 304379
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Also see D33429 for other ThinLTO + New PM related changes.
Reviewers: davide, chandlerc, tejohnson
Subscribers: mehdi_amini, Prazek, cfe-commits, inglorion, llvm-commits, eraman
Differential Revision: https://reviews.llvm.org/D33525
llvm-svn: 304378
|
| |
|
|
| |
llvm-svn: 304377
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike the GCC-compatible __has_trivial_destructor trait, this one computes the
right answer rather than performing the quirky set of checks described in GCC's
documentation (https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html).
MSVC also has a __has_trivial_destructor trait which is the same as its (and
now Clang's) __is_trivially_destructible trait; we might want to consider
changing the behavior of __has_trivial_destructor if we're targeting an MSVC
platform, but I'm not doing so for now.
While implementing this I found that we were incorrectly rejecting
__is_destructible queries on arrays of unknown bound of incomplete types; that
too is fixed, and I've added similar tests for other traits for good measure.
llvm-svn: 304376
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D33694
llvm-svn: 304375
|
| |
|
|
|
|
|
|
|
|
| |
Refactor cmake to remove dependence on LLVM's cmake modules.
This improves handling of cmake checks when cross compiling and brings
libcxxabi in line with libcxx and other project modules.
Differential revision: https://reviews.llvm.org/D33635
llvm-svn: 304374
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
@rsmith Does this correctly address the issues mentioned in https://reviews.llvm.org/D33625#inline-292971 ?
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D33636
llvm-svn: 304373
|