| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Patch by Guansong Zhang.
Differential Revision: https://reviews.llvm.org/D30784
llvm-svn: 297562
|
|
|
|
| |
llvm-svn: 297561
|
|
|
|
| |
llvm-svn: 297560
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title.
Reviewers: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30836
llvm-svn: 297559
|
|
|
|
| |
llvm-svn: 297558
|
|
|
|
| |
llvm-svn: 297557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since v_max_f32_e64/v_max_f16_e64 can be folded if the target
instruction supports the clamp bit, we also need to maintain
modifiers when converting v_mac to v_mad.
This fixes a rendering issue with Dirt Rally because a v_mac
instruction with the clamp bit set was converted to a v_mad
but that bit was lost during the conversion.
Fixes: e184e01dd79 ("AMDGPU: Fold FP clamp as modifier bit")
Patch by Samuel Pitoiset <samuel.pitoiset@gmail.com>
llvm-svn: 297556
|
|
|
|
| |
llvm-svn: 297555
|
|
|
|
| |
llvm-svn: 297554
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang doesn't produce gcov compatible coverage files. This
causes lcov to break because it uses gcov by default. This
patch switches lcov to use llvm-cov as the gcov-tool.
Unfortunatly llvm-cov doesn't provide a gcov like interface by
default so it won't work with lcov. However `llvm-cov gcov` does.
For this reason we generate 'llvm-cov-wrapper' script that always
passes the gcov flag.
llvm-svn: 297553
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30857
llvm-svn: 297552
|
|
|
|
|
|
| |
(https://github.com/google/oss-fuzz/issues/445)
llvm-svn: 297551
|
|
|
|
| |
llvm-svn: 297550
|
|
|
|
| |
llvm-svn: 297549
|
|
|
|
| |
llvm-svn: 297548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some coroutine diagnostics need to point to the location of the first coroutine keyword in the function, like when diagnosing a `return` inside a coroutine. Previously we did this by storing each *valid* coroutine statement in a list and select the first one to use in diagnostics. However if every coroutine statement is invalid we would have no location to point to.
This patch fixes the storage of the first coroutine statement location, ensuring that it gets stored even when the resulting AST node would be invalid.
This patch also removes the `CoroutineStmts` list in `FunctionScopeInfo` because it was unused.
Reviewers: rsmith, GorNishanov, aaron.ballman
Reviewed By: GorNishanov
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D30776
llvm-svn: 297547
|
|
|
|
|
|
| |
(https://github.com/google/oss-fuzz/issues/445)
llvm-svn: 297546
|
|
|
|
|
|
|
|
| |
When CMAKE_INSTALL_MANDIR isn't defined it ends up attempting to install
the man pages under "/man1" and we really don't want to accidentally install
stuff at the filesystem root.
llvm-svn: 297545
|
|
|
|
|
|
| |
number of edges, not yet suitable for unit testing
llvm-svn: 297544
|
|
|
|
| |
llvm-svn: 297543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Ths "cases" support was not quite finished, is unused, and is really just debug counters.
(well, almost, debug counters are slightly more powerful, in that they can skip things at the start, too).
Note, opt-bisect itself could also be implemented as a wrapper around
debug counters, but not sure it's worth it ATM.
I'll shove it on a todo list if we think it is.
Reviewers: MatzeB, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30856
llvm-svn: 297542
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Create only one OpaqueValue for await_ready/await_suspend/await_resume.
Store OpaqueValue used in the CoroutineSuspendExpr node, so that CodeGen does not have to hunt looking for it.
Reviewers: rsmith, EricWF, aaron.ballman
Reviewed By: EricWF
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D30775
llvm-svn: 297541
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r297310 began inserting red zones around allocations under ASan, which
perturbs the alignment of subsequent allocations. Deliberately specify
this in two places where it matters.
Fixes failures when these tests are run under ASan and UBSan together.
Reviewed by Duncan Exon Smith.
rdar://problem/30980047
llvm-svn: 297540
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change solves the same problem as D30726, except that this only
throws out the bathwater.
AST was not correctly tracking and deleting UnknownInstructions via
handles. The existing code only tracks "pointers" in its
`ASTCallbackVH`, so an UnknownInstruction (that isn't also def'ing a
pointer used by another memory instruction) never gets a
`ASTCallbackVH`.
There are two other ways to solve this problem:
- Use the `PointerRec` scheme for both known and unknown instructions.
- Use a `CallbackVH` that erases the offending Instruction from the
UnknownInstruction list.
Both of the above changes seemed to be significantly (and unnecessarily
IMO) more complex than this.
Reviewers: chandlerc, dberlin, hfinkel, reames
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D30849
llvm-svn: 297539
|
|
|
|
| |
llvm-svn: 297538
|
|
|
|
| |
llvm-svn: 297537
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method inverts the Reason field of a scheduling candidate.
It does right comparison between RegCritical and RegExcess, but
everything else is broken. In fact it can prefer less strong reason
such as Weak over RegCritical because Weak > -RegCritical.
The CandReason enum is properly sorted, so just remove artificial
ranking.
Differential Revision: https://reviews.llvm.org/D30557
llvm-svn: 297536
|
|
|
|
|
|
|
|
| |
We don't need to check whether the fallback path is enabled to return
false. Just do that all the time on error cases, the caller knows (or
at least should know!) how to handle the failing case.
llvm-svn: 297535
|
|
|
|
|
|
|
|
|
|
|
| |
The problem can occur in presence of subregs. If we are swapping two
instructions defining different subregs of the same register we will
get a new liveout from a block. We need to preserve value number for
block's liveout for successor block's livein to match.
Differential Revision: https://reviews.llvm.org/D30558
llvm-svn: 297534
|
|
|
|
|
|
| |
Still broken on Windows and SystemZ bot ... sorry for the noise.
llvm-svn: 297533
|
|
|
|
| |
llvm-svn: 297532
|
|
|
|
| |
llvm-svn: 297531
|
|
|
|
|
|
| |
to specify triple=x86_64-unknown.
llvm-svn: 297530
|
|
|
|
| |
llvm-svn: 297529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified the tests to accept any iteration order.
The VFS directory iterator and recursive directory iterator behave differently
from the LLVM counterparts. Once the VFS iterators hit a broken symlink they
immediately abort. The LLVM counterparts allow to recover from this issue by
clearing the error code and skipping to the next entry.
This change adds the same functionality to the VFS iterators. There should be
no change in current behavior in the current CLANG source base, because all
clients have loop exit conditions that also check the error code.
This fixes rdar://problem/30934619.
Differential Revision: https://reviews.llvm.org/D30768
llvm-svn: 297528
|
|
|
|
|
|
| |
'!A || (A && B)' is equivalent to '!A || B'
llvm-svn: 297527
|
|
|
|
|
|
| |
Use Liveness::getNearestAliasedRef to find the reaching def instead.
llvm-svn: 297526
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30628
llvm-svn: 297525
|
|
|
|
|
|
|
|
| |
This function will find the closest ref node aliased to Reg that is
in an instruction preceding Inst. This could be used to identify the
hypothetical reaching def of Reg, if Reg was a member of Inst.
llvm-svn: 297524
|
|
|
|
|
|
| |
This only requires a 64-bit memory source, not the whole 128-bits. But the 128-bit case is still supported via X86InstrInfo::foldMemoryOperandImpl
llvm-svn: 297523
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the isl::val constructor only takes a signed long as parameter, which
on Windows is only 32 bit large and can consequently not be used to obtain the
same result when loading from the expression '(1ull << 32) - 1)' that we get
when loading this value via isl_val_int_from_ui or when loading the value
on Linux systems with 64 bit long data types. We avoid this issue by performing
the shift and subtractiong within the isl::val.
It would be nice to teach the isl++ bindings to construct isl::val from other
integer types, but the current interface is not sufficient to do so. If
constructors from both signed long and unsigned long are exposed, then integer
literals that are of type 'int' and which must be converted to 'long' to match
the constructor have two ambigious constructors to choose from, which result
in a compiler error. The right solution is likely to additionally expose
constructors from signed and unsigned int, but these are not yet available in
the isl C interface and adding those adhoc to our bindings is something I would
like to avoid for now. We should address this issue with a proper discussion
on the isl side.
llvm-svn: 297522
|
|
|
|
| |
llvm-svn: 297521
|
|
|
|
|
|
| |
These were missed in r297478. We add them for consistency.
llvm-svn: 297520
|
|
|
|
|
|
|
|
|
| |
As most discussions about these bindings have concluded and only the final
patch review on the isl mailing list is missing, we drop the experimental
warning tag to match the patchset we will submit to isl, which is expected to
not change notably any more.
llvm-svn: 297519
|
|
|
|
| |
llvm-svn: 297518
|
|
|
|
|
|
| |
The tests are failing on one of the bots.
llvm-svn: 297517
|
|
|
|
| |
llvm-svn: 297516
|
|
|
|
| |
llvm-svn: 297515
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30555
llvm-svn: 297514
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30553
llvm-svn: 297513
|