| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As explained by the comment, threads will typically see different values
returned by atomic instructions even if the arguments are equal.
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18156
llvm-svn: 263719
|
| |
|
|
|
|
|
|
| |
We were being too aggressive in trying to combine a shuffle into a blend-with-zero pattern, often resulting in a endless loop of contrasting combines
This patch stops the combine if we already have a blend in place (means we miss some domain corrections)
llvm-svn: 263717
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is similar to D18133 where we allowed profile weights on select instructions.
This extends that change to also allow the 'unpredictable' attribute of branches to apply to selects.
A test to check that 'unpredictable' metadata is preserved when cloning instructions was checked in at:
http://reviews.llvm.org/rL263648
Differential Revision: http://reviews.llvm.org/D18220
llvm-svn: 263716
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The two changes together weakened the test and caused a regression with division
handling in MSVC mode. They were applied to avoid an assertion being triggered
in the block frequency analysis. However, the underlying problem was simply
being masked rather than solved properly. Address the actual underlying problem
and revert the changes. Rather than analyze the cause of the assertion, the
division failure was assumed to be an overflow.
The underlying issue was a subtle bug in the BB construction in the emission of
the div-by-zero check (WIN__DBZCHK). We did not construct the proper successor
information in the basic blocks, nor did we update the PHIs associated with the
basic block when we split them. This would result in assertions being triggered
in the block frequency analysis pass.
Although the original tests are being removed, the tests themselves performed
very little in terms of validation but merely tested that we did not assert when
generating code. Update this with new tests that actually ensure that we do not
regress on the code generation.
llvm-svn: 263714
|
| |
|
|
| |
llvm-svn: 263708
|
| |
|
|
|
|
|
|
|
|
|
| |
hex format
It might be hard to recognize a hexadecimal number without '0x' prefix.
Besides that '0x' prefix corresponds to GNU objdump behaviour.
Differential Revision: http://reviews.llvm.org/D18207
llvm-svn: 263705
|
| |
|
|
|
|
|
|
|
| |
That allows, for example, to print hex-formatted immediates using
llvm-objdump --print-imm-hex command line option.
Differential Revision: http://reviews.llvm.org/D18195
llvm-svn: 263704
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
warnings, NFC
Summary:
This should eliminate all occurrences of this within LLVMMipsAsmParser.
This patch is in response to http://reviews.llvm.org/D17983. I was unable
to reproduce the warnings on my machine so please advise if this fixes the
warnings.
Reviewers: ariccio, vkalintiris, dsanders
Subscribers: dblaikie, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D18087
llvm-svn: 263703
|
| |
|
|
|
|
| |
TypeResolve went away in r134829 in 2011.
llvm-svn: 263702
|
| |
|
|
| |
llvm-svn: 263700
|
| |
|
|
| |
llvm-svn: 263697
|
| |
|
|
| |
llvm-svn: 263696
|
| |
|
|
|
|
|
|
|
| |
The section alignment field was marked optional but not provided a
default value: initialize it with 0.
While we are here, ensure that the section alignment is plausible.
llvm-svn: 263692
|
| |
|
|
|
|
|
|
|
|
|
| |
This splits out the logic that maps the `"statepoint-id"` attribute into
the actual statepoint ID, and the `"statepoint-num-patch-bytes"`
attribute into the number of patchable bytes the statpeoint is lowered
into. The new home of this logic is in IR/Statepoint.cpp, and this
refactoring will support similar functionality when lowering calls with
deopt operand bundles in the future.
llvm-svn: 263685
|
| |
|
|
| |
llvm-svn: 263684
|
| |
|
|
|
|
|
| |
Mostly code simplifcations, and bringing up IR/Statepoints.cpp up to
LLVM coding style.
llvm-svn: 263683
|
| |
|
|
|
|
|
| |
This way we have a single entry point into StatepointLowering. The
method was a direct dispatch to LowerStatepoint anyway.
llvm-svn: 263682
|
| |
|
|
|
|
|
|
|
|
| |
The allocator here can still be a nullptr, but this atleast makes the
single caller which needed nullptr be explicit about it.
Note, lld started always passing a parameter here as of r263680. If
anything builds out of sync, that would be why errors may occur.
llvm-svn: 263681
|
| |
|
|
| |
llvm-svn: 263679
|
| |
|
|
|
|
|
|
|
|
| |
In lld we allocate atoms on an allocator and so don't run their
destructors. This means we also shouldn't allocate memory inside
them without that also being on an allocator.
Reviewed by Lang Hames and Rafael Espindola.
llvm-svn: 263676
|
| |
|
|
| |
llvm-svn: 263675
|
| |
|
|
| |
llvm-svn: 263674
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: If TBAA is on an intrinsic and it gets upgraded and drops the TBAA we hit an odd assert. We should just upgrade the TBAA first because it doesn't have side-effects.
Reviewers: reames, apilipenko, manmanren
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18229
llvm-svn: 263673
|
| |
|
|
| |
llvm-svn: 263672
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a step towards implementing "direct" lowering of calls and
invokes with deopt operand bundles into STATEPOINT nodes (as opposed to
having them mandatorily pass through RewriteStatepointsForGC, which is
the case today).
This change extracts out a `SelectionDAGBuilder::LowerAsStatepoint`
helper function that is able to lower a "statepoint like thing", and
uses it to lower `gc.statepoint` calls. This is an NFC now, but in a
later change we will use `LowerAsStatepoint` to directly lower calls and
invokes with operand bundles without going through an intermediate
`gc.statepoint` IR representation.
FYI: I expect `SelectionDAGBuilder::StatepointInfo` will evolve as I add
support for lowering non gc.statepoints, right now it is fairly tightly
coupled with an IR level `gc.statepoint`.
Reviewers: reames, pgavlin, JosephTremoulet
Subscribers: sanjoy, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18106
llvm-svn: 263671
|
| |
|
|
|
|
|
|
| |
I'm testing out a script that auto-generates the check lines.
It's 98% copied from utils/update_llc_test_checks.py.
If others think this is useful, please let me know.
llvm-svn: 263668
|
| |
|
|
|
|
|
|
| |
I'm testing out a script that auto-generates the check lines.
It's 98% copied from utils/update_llc_test_checks.py.
If others think this is useful, please let me know.
llvm-svn: 263667
|
| |
|
|
| |
llvm-svn: 263666
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Rename getATOMIC to getSYNC, as llvm will soon be able to emit both
'__sync' libcalls and '__atomic' libcalls, and this function is for
the '__sync' ones.
- getInsertFencesForAtomic() has been replaced with
shouldInsertFencesForAtomic(Instruction), so that the decision can be
made per-instruction. This functionality will be used soon.
- emitLeadingFence/emitTrailingFence are no longer called if
shouldInsertFencesForAtomic returns false, and thus don't need to
check the condition themselves.
llvm-svn: 263665
|
| |
|
|
|
|
|
|
|
| |
SelectionDAGBuilder::populateCallLoweringInfo is now used instead of
SelectionDAGBuilder::lowerCallOperands. The populateCallLoweringInfo
interface is more composable in face of design changes like
http://reviews.llvm.org/D18106
llvm-svn: 263663
|
| |
|
|
|
|
|
|
|
|
|
| |
The swift frontend needs to be able to look up PGO function name
variables based on the original raw function name. That's because it's
not possible to create PGO function name variables while emitting swift
IR. Instead, we have to create the name variables while lowering swift
IR to llvm IR, at which point we fix up all calls to the increment
intrinsic to point to the right name variable.
llvm-svn: 263662
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Uniform loops where the branch leaving the loop is predicated on VCCNZ
must be skipped if EXEC = 0, otherwise they will be infinite.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18137
llvm-svn: 263658
|
| |
|
|
|
|
| |
have been appended to the end.
llvm-svn: 263657
|
| |
|
|
| |
llvm-svn: 263656
|
| |
|
|
|
|
| |
This reverts commit r263644. Investigating bootstrap failures.
llvm-svn: 263655
|
| |
|
|
| |
llvm-svn: 263650
|
| |
|
|
|
|
| |
PR26953 cases
llvm-svn: 263649
|
| |
|
|
| |
llvm-svn: 263648
|
| |
|
|
| |
llvm-svn: 263646
|
| |
|
|
| |
llvm-svn: 263645
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix LSRInstance::HoistInsertPosition() to check the original insert
position block first for a canonical insertion point that is dominated
by all inputs. This leads to SCEV being able to reuse more instructions
since it currently tracks the instructions it creates for reuse by
keeping a table of <Value, insert point> pairs.
Reviewers: atrick
Subscribers: mcrosier, mzolotukhin, llvm-commits
Differential Revision: http://reviews.llvm.org/D18001
llvm-svn: 263644
|
| |
|
|
|
|
|
| |
- Ensure we test X86 + X64
- sitopfp / uitofp requires testing for SSE2 and SSE42 as well (part of the fix for PR26953)
llvm-svn: 263640
|
| |
|
|
|
|
|
|
|
|
|
|
| |
And emit an error if it fails.
This prevents illegal instructions from getting sent to the GPU, which
would potentially result in a hang.
This is a candidate for the stable branch(es).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
llvm-svn: 263627
|
| |
|
|
|
| |
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 263626
|
| |
|
|
|
|
|
|
| |
512bit vector because PCMPGT supported only for 128/256bit.
Differential Revision: http://reviews.llvm.org/D18204
llvm-svn: 263624
|
| |
|
|
|
|
|
| |
Fork off compatibility.ll for the 3.8 release. The *.bc file in this
commit was produced using a Release build of the release_38 branch.
llvm-svn: 263620
|
| |
|
|
|
|
| |
To capture more jump-thread opportunity.
llvm-svn: 263618
|
| |
|
|
| |
llvm-svn: 263610
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces the Error classs for lightweight, structured,
recoverable error handling. It includes utilities for creating, manipulating
and handling errors. The scheme is similar to exceptions, in that errors are
described with user-defined types. Unlike exceptions however, errors are
represented as ordinary return types in the API (similar to the way
std::error_code is used).
For usage notes see the LLVM programmer's manual, and the Error.h header.
Usage examples can be found in unittests/Support/ErrorTest.cpp.
Many thanks to David Blaikie, Mehdi Amini, Kevin Enderby and others on the
llvm-dev and llvm-commits lists for lots of discussion and review.
llvm-svn: 263609
|
| |
|
|
| |
llvm-svn: 263608
|