| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: The macro was introduced with D26929, use it in Scudo as well.
Reviewers: kcc, alekseyshl, kubabrecka
Subscribers: llvm-commits, danalbert, srhines, mgorny
Differential Revision: https://reviews.llvm.org/D28066
llvm-svn: 290439
|
| |
|
|
| |
llvm-svn: 290438
|
| |
|
|
| |
llvm-svn: 290437
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We compile user opencl kernel code with spir triple. But built-ins are written in OpenCL and we compile it with triple x86_64 to be able to use x86 intrinsics. And we need address spaces to match in both cases. So, we change fake address space map in OpenCL for matching with spir.
On CPU address spaces are not really important but we'd like to preserve address space information in order to perform optimizations relying on this info like enhanced alias analysis.
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: pekka.jaaskelainen, yaxunl, bader, cfe-commits
Differential Revision: https://reviews.llvm.org/D28048
llvm-svn: 290436
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27989
llvm-svn: 290435
|
| |
|
|
| |
llvm-svn: 290434
|
| |
|
|
| |
llvm-svn: 290433
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
operand."
Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171
Reviewers: djasper, Anastasia
Subscribers: yaxunl, cfe-commits, bader
Differential Revision: https://reviews.llvm.org/D27981
llvm-svn: 290431
|
| |
|
|
| |
llvm-svn: 290428
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pass creates some state which expects to be cleaned up by
a later instance of the same pass. opt-bisect happens to expose
this not ideal design because calling skipLoop() will result in
this state not being cleaned up at times and an assertion firing
in `doFinalization()`. Chandler tells me the new pass manager will
give us options to avoid these design traps, but until it's not ready,
we need a workaround for the current pass infrastructure. Fix provided
by Andy Kaylor, see the review for a complete discussion.
Differential Revision: https://reviews.llvm.org/D25848
llvm-svn: 290427
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the Cortex-A57 doc, FDIV/FSQRT instructions should use F0 unit
(W-unit in AArch64SchedA57.td, the same as cryptography instructions),
not F1 unit (X-unit in td, like ASIMD absolute diff accum SABA/UABA).
This patch changes FDIV/FSQRT scheduling declarations to use A57UnitW
instead of A57UnitX. Also, latencies for those instructions are
corrected.
Patch by Andrew Zhogin.
llvm-svn: 290426
|
| |
|
|
| |
llvm-svn: 290425
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Bunch of fixed bugs in Clang after running misc-use-after-move in clang-tidy.
Reviewers: rsmith, mboehme
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D27752
llvm-svn: 290424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In mergeSPUpdates, debug values need to be ignored when getting the
previous element, otherwise debug data could have an impact on codegen.
In eliminateCallFramePseudoInstr, debug values after the erased element
could have an impact on codegen and should be skipped.
Closes PR31319 (https://llvm.org/bugs/show_bug.cgi?id=31319)
Reviewers: mkuper, MatzeB, aprantl
Subscribers: gbedwell, llvm-commits
Differential Revision: https://reviews.llvm.org/D27688
llvm-svn: 290423
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix missing "int_lib.h" includes in ARM negdf2vfp and subdf3vfp tests.
Additionally, extend the __arm__ guard to cover the builtin definition
in the former. This is mostly intended to prevent build failures
and allow those tests to be properly skipped on other targets.
Differential Revision: https://reviews.llvm.org/D28078
llvm-svn: 290422
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: hokein
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28052
llvm-svn: 290421
|
| |
|
|
| |
llvm-svn: 290420
|
| |
|
|
|
|
|
|
|
|
| |
building .gdb_index
This fixes issue revealed by r289961.
Differential revision: https://reviews.llvm.org/D28045
llvm-svn: 290419
|
| |
|
|
|
|
| |
througput -> throughput
llvm-svn: 290418
|
| |
|
|
|
|
|
|
|
|
|
| |
diagnostics and fix one such diagnostic.
Sadly, this assert doesn't catch this bug because we have no tests that
emit this diagnostic! Doh! I'm following up on the commit that
introduces it to get that fixed. Then this assert will help in a more
direct way.
llvm-svn: 290417
|
| |
|
|
|
|
| |
assertions are enabled (NFC)
llvm-svn: 290416
|
| |
|
|
| |
llvm-svn: 290415
|
| |
|
|
|
|
|
|
|
| |
its own function (NFC)
This is pure code motion, will just make it more reusable when I'll
attempt to lazy-load Metadats on-demand.
llvm-svn: 290414
|
| |
|
|
|
|
|
|
|
| |
propagation from an operand of the logical operation to operation result.
The patch also simplifies an assume of a constraint of the form: "(exp comparison_op expr) != 0" to true into an assume of "exp comparison_op expr" to true. (And similarly, an assume of the form "(exp comparison_op expr) == 0" to true as an assume of exp comparison_op expr to false.) which improves precision overall.
https://reviews.llvm.org/D22862
llvm-svn: 290413
|
| |
|
|
|
|
| |
These will be used to guide the binary encoding of these immediates.
llvm-svn: 290412
|
| |
|
|
|
|
|
| |
We managed new MemoryBuffers in different ways in LinkerScript.cpp and
Driver.cpp. With this patch, they are managed in the same way.
llvm-svn: 290411
|
| |
|
|
|
|
|
|
|
|
|
| |
1.Fix pessimized case in FIXME.
2.Add tests for it.
3.The canonicalisation on shifts results in different sequence for
tests of machine-licm.Correct some check lines.
Differential Revision: https://reviews.llvm.org/D27916
llvm-svn: 290410
|
| |
|
|
|
|
| |
This put the Loader back in a consistent state.
llvm-svn: 290409
|
| |
|
|
|
|
| |
while loading Metadata (NFC)
llvm-svn: 290408
|
| |
|
|
| |
llvm-svn: 290407
|
| |
|
|
|
|
|
|
| |
(NFC)
Keeping all the state together will make it easier to handle.
llvm-svn: 290406
|
| |
|
|
|
|
|
| |
out of an internal function and into ASTContext; this is needed in template
argument deduction for P0522R0.
llvm-svn: 290405
|
| |
|
|
|
|
|
| |
frustrating Subversion clients that fails to do line ending translation
of text files.
llvm-svn: 290404
|
| |
|
|
|
|
|
|
|
|
| |
twice, in finalization of template argument deduction.
This is a re-commit of r290310 (reverted in r290329); the bug found by the
buildbots was fixed in r290399 (we would sometimes build a deduced template
argument with a bogus type).
llvm-svn: 290403
|
| |
|
|
| |
llvm-svn: 290402
|
| |
|
|
|
|
| |
Win32 API directly.
llvm-svn: 290401
|
| |
|
|
|
|
|
|
| |
find.
Notable is the assert in NewGVN which had no effect because of the bug.
llvm-svn: 290400
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fail the merge if the arguments have different types (except if one of them was
deduced from an array bound, in which case take the type from the other).
This is correct because (except in the array bound case) the type of the
template argument in each deduction must match the type of the parameter, so at
least one of the two deduced arguments must have a mismatched type.
This is necessary because we would otherwise lose the type information for the
discarded template argument in the merge, and fail to diagnose the mismatch.
In order to power this, we now properly retain the type of a deduced non-type
template argument deduced from a declaration, rather than giving it the type of
the template parameter; we'll convert it to the template parameter type when
checking the deduced arguments.
llvm-svn: 290399
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fno-inline-functions, -O0, and optnone.
These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
- But not for -fno-inline-functions (breaking LTO)
- But we did use it for -finline-hint-functions (yay, LTO is happy!)
- But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
enumeration and a boolean. They interacted in weird ways and
needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
onto many generated function definitions because they didn't show up
as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
inliner pass in LLVM despite it being in the O0 pipeline, which really
doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
pipeline which forced the pass pipeline to be much more
parameterizable than it really needs to be. Instead we can *just* use
the optimization level to select a pipeline and control the rest via
attributes.
Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.
I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.
One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.
Differential Revision: https://reviews.llvm.org/D28053
llvm-svn: 290398
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes some ASAN unittest failures on FreeBSD. See the
cfe-commits email thread for r290169 for more on those.
According to the LangRef, the allocsize attribute only tells us about
the number of bytes that exist at the memory location pointed to by the
return value of a function. It does not necessarily mean that the
function will only ever allocate. So, we need to be very careful about
treating functions with allocsize as general allocation functions. This
patch makes us fully conservative in this regard, though I suspect that
we have room to be a bit more aggressive if we want.
This has a FIXME that can be fixed by a relatively straightforward
refactor; I just wanted to keep this patch minimal. If this sticks, I'll
come back and fix it in a few days.
llvm-svn: 290397
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis
Subscribers: kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D28072
llvm-svn: 290396
|
| |
|
|
|
|
| |
Extract out two large lambdas into top level member functions.
llvm-svn: 290395
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change rewrites a core component in the ImplicitNullChecks pass for
greater simplicity since the original design was over-complicated for no
good reason. Please review this as essentially a new pass. The change
is almost NFC and I've added a test case for a scenario that this new
code handles that wasn't handled earlier.
The implicit null check pass, at its core, is a code hoisting transform.
It differs from "normal" code transforms in that it speculates
potentially faulting instructions (by design), but a lot of the usual
hazard detection logic (register read-after-write etc.) still applies.
We previously detected hazards by keeping track of registers defined and
used by machine instructions over an instruction range, but that was
unwieldy and did not actually confer any performance benefits. The
intent was to have linear time complexity over the number of machine
instructions considered, but it ended up being N^2 is practice.
This new version is more obviously O(N^2) (with N capped to 8 by
default) in hazard detection. It does not attempt to be clever in
tracking register uses or defs (the previous cleverness here was a
source of bugs).
Once this is checked in, I'll extract out the `IsSuitableMemoryOp` and
`CanHoistLoadInst` lambda into member functions (they're too complicated
to be inline lambdas) and do some other related NFC cleanups.
Reviewers: reames, anna, atrick
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D27592
llvm-svn: 290394
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: We setup these interceptors twice which hangs test on windows.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D28070
llvm-svn: 290393
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.
There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.
This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.
This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.
Differential Revision: https://reviews.llvm.org/D28047
llvm-svn: 290392
|
| |
|
|
|
|
|
|
|
|
| |
This is necessary for the distribution targets which assume that
each component has an install target. This also moves the CMake
macros into a separate file akin to other LLVM projects.
Differential Revision: https://reviews.llvm.org/D27876
llvm-svn: 290391
|
| |
|
|
|
|
| |
holder should point to it.
llvm-svn: 290390
|
| |
|
|
| |
llvm-svn: 290389
|
| |
|
|
|
|
| |
Accidentally re-defined the variable instead of setting it. Oops!
llvm-svn: 290388
|
| |
|
|
|
|
| |
I missed those in my previous commit (r290378).
llvm-svn: 290387
|