| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
When MachineCopyPropagation eliminates a dead 'copy', its associated debug information becomes invalid. as the recorded register has been removed. It causes the debugger to display wrong variable value.
Differential Revision: https://reviews.llvm.org/D52614
llvm-svn: 343445
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
physical registers and k-registers.
We can only copy between a k-register and a GR32/GR64 register.
This patch detects that the copy will be illegal and prevents the domain reassignment from happening for that closure.
This probably isn't the best fix, and we should probably figure out how to handle this correctly.
Fixes PR38803.
llvm-svn: 343443
|
| |
|
|
|
|
| |
copy.
llvm-svn: 343442
|
| |
|
|
|
|
|
|
| |
libraries on disk, and for the current process.
Avoids more boilerplate during JIT construction.
llvm-svn: 343430
|
| |
|
|
|
|
|
|
| |
will stop making us reach the other report_fatal_error in this function.
There's a conditional report_fatal_error just above this llvm_unreachable. The optimizer when seeing the unreachable removes the conditional and just makes any other error trigger the existing report_fatal_error.
llvm-svn: 343428
|
| |
|
|
|
|
|
| |
This cuts down on boilerplate by reducing 'ES.getSymbolStringPool().intern(...)'
to 'ES.intern(...)'.
llvm-svn: 343427
|
| |
|
|
|
|
|
| |
There are a few leftovers in rL343163 which span two lines. This commit
changes these llvm::sort(C.begin(), C.end, ...) to llvm::sort(C, ...)
llvm-svn: 343426
|
| |
|
|
|
|
| |
This wasn't treated as a folded load instruction
llvm-svn: 343424
|
| |
|
|
|
|
|
|
|
|
|
| |
(1) Adds comments for the API.
(2) Removes the setArch method: This is redundant: the setArchStr method on the
triple should be used instead.
(3) Turns EmulatedTLS on by default. This matches EngineBuilder's behavior.
llvm-svn: 343423
|
| |
|
|
| |
llvm-svn: 343419
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The lowering of PHI nodes used to detect if all inputs originated
from IMPLICIT_DEF's. If so the PHI node was replaced by an
IMPLICIT_DEF. Now we also consider undef uses when checking the
inputs. So if all inputs are implicitly defined or undef we
lower the PHI to an IMPLICIT_DEF. This makes
PHIElimination::LowerPHINode more consistent as it checks
both implicit and undef properties at later stages.
Reviewers: MatzeB, tstellar
Reviewed By: MatzeB
Subscribers: jvesely, nhaehnle, llvm-commits
Differential Revision: https://reviews.llvm.org/D52558
llvm-svn: 343417
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When PR16508 was solved (in rL185363) a regression test was
added as test/CodeGen/PowerPC/2013-07-01-PHIElimBug.ll.
I discovered that the test case no longer reproduced the
scenario from PR16508. This problem could have been amended
by adding an extra RUN line with "-O1" (or possibly "-O0"),
but instead I added a mir-reproducer
test/CodeGen/PowerPC/2013-07-01-PHIElimBug.mir
to get a reproducer that is less sensitive to changes in
earlier passes (including O-level).
While being at it I also corrected a code comment in
PHIElimination::EliminatePHINodes that has been incorrect
since the related bugfix from rL185363.
Reviewers: MatzeB, hfinkel
Reviewed By: MatzeB
Subscribers: nemanjai, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D52553
llvm-svn: 343416
|
| |
|
|
|
|
|
|
| |
Missing JFPU0 pipe and double JFPU1 pipe (to match JVALU1) resources
Match AMD Fam16h SOG + llvm-exegesis tests
llvm-svn: 343413
|
| |
|
|
| |
llvm-svn: 343412
|
| |
|
|
|
|
| |
Some instructions take an extra load uop - but not consistently.....
llvm-svn: 343410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This transform is requested for the backend in:
https://bugs.llvm.org/show_bug.cgi?id=39016
...but I figured it was worth doing in IR too, and it's probably
easier to implement here, so that's this patch.
In the simplest case, we are just truncating a scalar value. If the
extract index doesn't correspond to the LSBs of the scalar, then we
have to shift-right before the truncate. Endian-ness makes this tricky,
but hopefully the ASCII-art helps visualize the transform.
Differential Revision: https://reviews.llvm.org/D52439
llvm-svn: 343407
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in post-commit comments for D52548, the limitation on
increasing vector length can be applied by opcode.
As a first step, this patch only allows insertelement to be
widened because that has no logical downsides for IR and has
little risk of pessimizing codegen.
This may cause PR39132 to go into hiding during a full compile,
but that bug is not fixed.
llvm-svn: 343406
|
| |
|
|
|
|
|
|
| |
The SINT_TO_FP<->UINT_TO_FP combines for non-negative integers should only occur for legal ops once LegalOperations = true
No test case to hand, noticed when investigating PR38226 + PR38970
llvm-svn: 343405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on compiling for a CPU with single uop BEXTR
Summary:
This function turns (X >> C1) & C2 into a BMI BEXTR or TBM BEXTRI instruction. For BMI BEXTR we have to materialize an immediate into a register to feed to the BEXTR instruction.
The BMI BEXTR instruction is 2 uops on Intel CPUs. It looks like on SKL its one port 0/6 uop and one port 1/5 uop. Despite what Agner's tables say. I know one of the uops is a regular shift uop so it would have to go through the port 0/6 shifter unit. So that's the same or worse execution wise than the shift+and which is one 0/6 uop and one 0/1/5/6 uop. The move immediate into register is an additional 0/1/5/6 uop.
For now I've limited this transform to AMD CPUs which have a single uop BEXTR. If may also might make sense if we can fold a load or if the and immediate is larger than 32-bits and can't be encoded as a sign extended 32-bit value or if LICM or CSE can hoist the move immediate and share it. But we'd need to look more carefully at that. In the regression I looked at it doesn't look load folding or large immediates were occurring so the regression isn't caused by the loss of those. So we could try to be smarter here if we find a compelling case.
Reviewers: RKSimon, spatel, lebedev.ri, andreadb
Reviewed By: RKSimon
Subscribers: llvm-commits, andreadb, RKSimon
Differential Revision: https://reviews.llvm.org/D52570
llvm-svn: 343399
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
CompileOnDemandLayer2 now supports user-supplied partition functions (the
original CompileOnDemandLayer already supported these).
Partition functions are called with the list of requested global values
(i.e. global values that currently have queries waiting on them) and have an
opportunity to select extra global values to materialize at the same time.
Also adds testing infrastructure for the new feature to lli.
llvm-svn: 343396
|
| |
|
|
|
|
|
| |
The map is inaccessible at this point, so we may as well reclaim the memory
early.
llvm-svn: 343395
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We didn't properly detect when a pointer was a member
pointer, and when that was the case we were not
properly returning class parent info. This caused
member pointers to render incorrectly in pretty mode.
However, we didn't even have pretty tests for pointers
in native mode, so those are also added now to ensure
this.
llvm-svn: 343393
|
| |
|
|
|
|
|
|
| |
shuffles before simplifying inputs
By removing demanded target shuffles that simplify to zero/undef/identity before simplifying its inputs we improve chances of further simplification, as only the immediate parent user of the combined is added back to the work list - this still doesn't help us if its passed through other ops though (bitcasts....).
llvm-svn: 343390
|
| |
|
|
|
|
|
|
| |
handling.
This is all handled generally by getTargetConstantBitsFromNode now
llvm-svn: 343387
|
| |
|
|
| |
llvm-svn: 343385
|
| |
|
|
|
|
|
|
| |
bits via shuffles
Exposed an issue that recursive calls to getTargetConstantBitsFromNode don't handle changes to EltSizeInBits yet.
llvm-svn: 343384
|
| |
|
|
|
|
|
|
|
|
| |
get immediate data
Don't just attempt to find a splat build vector.
First step towards getting rid of all the 32-bit special case code.
llvm-svn: 343383
|
| |
|
|
|
|
| |
We need to alter the functionality as shown in D52548.
llvm-svn: 343379
|
| |
|
|
|
|
| |
builds due to rL343375
llvm-svn: 343377
|
| |
|
|
|
|
| |
ISD::EXTRACT_SUBVECTOR
llvm-svn: 343375
|
| |
|
|
|
|
| |
The shift amount might have peeked through a extract_subvector, altering the number of vector elements in the 'Amt' variable - so we were incorrectly calculating the ratio when peeking through bitcasts, resulting in incorrectly detecting splats.
llvm-svn: 343373
|
| |
|
|
|
|
| |
rL343018 messed up the comment indentation while moving it.
llvm-svn: 343371
|
| |
|
|
| |
llvm-svn: 343369
|
| |
|
|
|
|
|
|
| |
This makes it available for use in IRTransformLayer2::TransformFunction
instances (since a const MaterializationResponsibility& parameter was
added in r343365).
llvm-svn: 343367
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(1) A const accessor for the LLVMContext held by a ThreadSafeContext.
(2) A const accessor for the ThreadSafeModules held by an IRMaterializationUnit.
(3) A const MaterializationResponsibility reference to IRTransformLayer2's
transform function. This makes IRTransformLayer2 useful for JIT debugging
(since it can inspect JIT state through the responsibility argument) as well
as program transformations.
llvm-svn: 343365
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This CL allows constant vectors of floats to be recognized as non-NaN
and non-zero in select patterns. This change makes
`matchSelectPattern` more powerful generally, but was motivated
specifically because I wanted fminnan and fmaxnan to be created for
vector versions of the scalar patterns they are created for.
Tested with check-all on all targets. A testcase in the WebAssembly
backend that tests the non-nan codepath is in an upcoming CL.
Reviewers: aheejin, dschuff
Subscribers: sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D52324
llvm-svn: 343364
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Before this, there was no reasonable way to retrieve the type of a global value (most notably, a function) that was created with the C API.
Reviewers: whitequark, deadalnix
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52659
llvm-svn: 343363
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: WasmEHFuncInfo objects were not being properly deleted.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D52582
llvm-svn: 343362
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Correctly check for relocations in the constant to promote. And don't
allow promoting a constant multiple times.
This partially fixes https://bugs.llvm.org//show_bug.cgi?id=32780 ;
it's not a complete fix because we also need to prevent
ARMConstantIslands from cloning the constant.
(-arm-promote-constant is currently off by default, and it stays off
with this patch. I'll look into turning it on again when all the known
issues are fixed.)
Differential Revision: https://reviews.llvm.org/D51472
llvm-svn: 343361
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly affects IR generated by non-clang frontends because clang
generally sets the alignment of globals explicitly.
Fixes https://bugs.llvm.org//show_bug.cgi?id=32394 .
(-arm-promote-constant is currently off by default, and it stays off
with this patch. I'll look into turning it on again when all the known
issues are fixed.)
Differential Revision: https://reviews.llvm.org/D51469
llvm-svn: 343359
|
| |
|
|
|
|
| |
GlobalVariables, not all GlobalValues.
llvm-svn: 343358
|
| |
|
|
|
|
|
|
|
|
| |
Split the `zcz` feature into specific ones got GP and FP registers, `zcz-gp`
and `zcz-fp`, respectively, while retaining the original feature option to
mean both.
Differential revision: https://reviews.llvm.org/D52621
llvm-svn: 343354
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: spatel
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52661
llvm-svn: 343349
|
| |
|
|
|
|
| |
- asan buildbots are breaking and I need to investigate the issue
llvm-svn: 343341
|
| |
|
|
|
|
|
|
|
| |
This reverts commit c4baf7c2f06ff5459c4f5998ce980346e72bff97.
Broke the bots, and should really be in Transforms/Coroutines
instead.
llvm-svn: 343337
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch adds bindings to C and Go for addCoroutinePassesToExtensionPoints, which is used to add coroutine passes to the correct locations in PassManagerBuilder.
Reviewers: whitequark, deadalnix
Reviewed By: whitequark
Subscribers: mehdi_amini, modocache, llvm-commits
Differential Revision: https://reviews.llvm.org/D51642
llvm-svn: 343336
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fix broken bots caused by the merge of D51522.
Reviewers: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52657
llvm-svn: 343334
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Adds missing debug information accessors to GlobalObject. This puts the finishing touches on cloning debug info in the echo tests.
Reviewers: whitequark, deadalnix
Reviewed By: whitequark
Subscribers: aprantl, JDevlieghere, llvm-commits, harlanhaskins
Differential Revision: https://reviews.llvm.org/D51522
llvm-svn: 343330
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InstCombine would propagate shufflevector insts that had wider output vectors onto
predecessors, which would sometimes push undef's onto the divisor of a div/rem and
result in bad codegen.
I've fixed this by just banning propagating shufflevector back if the result of
the shufflevector is wider than the input vectors.
Patch by: @sheredom (Neil Henning)
Differential Revision: https://reviews.llvm.org/D52548
llvm-svn: 343329
|
| |
|
|
| |
llvm-svn: 343327
|