This is part of the work to devirtualize Value.
The old pattern was to call replaceUsesOfWithOnConstant which was overridden by
subclasses. Those could then call replaceUsesOfWithOnConstantImpl on Constant
to handle deleting the current value.
To be consistent with other parts of the code, this has been changed so that we
call the method on Constant, and that dispatches to an Impl on subclasses.
As part of this, it made sense to rename the methods to be more descriptive. The
new name is Constant::handleOperandChange, and it requires that all subclasses of
Constant implement handleOperandChangeImpl, even if they just throw an error if
they shouldn't be called.
Reviewed by Duncan Exon Smith.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240567 91177308-0d34-0410-b5e6-96231b3b80d8
Stop taking a `dwarf::Form` in `DIEValue::EmitValue()` and
`DIEValue::SizeOf()`, since they're always passed `DIEValue::getForm()`
anyway. This is just left over from when `DIEValue` didn't know its own
form.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240566 91177308-0d34-0410-b5e6-96231b3b80d8
CaptureTracking becomes very expensive in large basic blocks while
calling PointerMayBeCaptured. PointerMayBeCaptured scans the BB the
number of times equal to the number of uses of 'BeforeHere', which is
currently capped at 20 and bails out with Tracker->tooManyUses().
The bottleneck here is the number of calls to PointerMayBeCaptured * the
basic block scan. In a testcase with a 82k instruction BB,
PointerMayBeCaptured is called 130k times, leading to 'shouldExplore'
taking 527k runs, this currently takes ~12min.
To fix this we locally (within PointerMayBeCaptured) number the
instructions in the basic block using a DenseMap to cache instruction
positions/numbers. We build the cache incrementally every time we need
to scan an unexplored part of the BB, improving compile time to only
take ~2min.
This triggers in the flow: DeadStoreElimination -> MepDepAnalysis ->
CaptureTracking.
Side note: after multiple runs in the test-suite I've seen no
performance nor compile time regressions, but could note a couple of
compile time improvements:
Performance Improvements - Compile Time Delta Previous Current StdDev
SingleSource/Benchmarks/Misc-C++/bigfib -4.48% 0.8547 0.8164 0.0022
MultiSource/Benchmarks/TSVC/LoopRerolling-dbl/LoopRerolling-dbl -1.47% 1.3912 1.3707 0.0056
Differential Revision: http://reviews.llvm.org/D7010
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240560 91177308-0d34-0410-b5e6-96231b3b80d8
This commit serializes the null register machine operands.
It uses the '_' keyword to represent them, but the parser
also allows the '%noreg' named register syntax.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10580
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240558 91177308-0d34-0410-b5e6-96231b3b80d8
With option OptForSize enabled, the Loop Vectorizer is not supposed to
create tail loop. The condition checking that was invalid and was not
matching to the comment above.
Patch by Marianne Mailhot-Sarrasin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240556 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch fixes PR23405 (https://llvm.org/bugs/show_bug.cgi?id=23405).
During a node unscheduling an entry in LiveRegGens can be replaced with a new value. That corrupts the live reg tracking and LiveReg* structure is not cleared as should be during unscheduling. Problematic condition that enforces Gen replacement is `I->getSUnit()->getHeight() < LiveRegGens[I->getReg()]->getHeight()`. This condition should be checked only if LiveRegGen was set in current node unscheduling.
Test Plan: Regression test included.
Reviewers: hfinkel, atrick
Reviewed By: atrick
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9993
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240538 91177308-0d34-0410-b5e6-96231b3b80d8
COFF and MachO only define symbol sizes for common symbols. Reflect that
in the class hierarchy by having a method for common symbols only in the base
and a general one in ELF.
This avoids the need of using a magic value for the size, which had a few
problems
* Most callers didn't check for it.
* The ones that did could not tell the magic value from a file actually having
that value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240529 91177308-0d34-0410-b5e6-96231b3b80d8
This stops shifting a 32-bit value by such absurd amounts as 96 and
120. We do this by dropping a call to the function that was doing this
entirely, which rather surprisingly doesn't break *any* tests.
I've also added an assert in the misbehaving function to prove that
it's no longer being called with completely invalid arguments.
This change looks pretty bogus and we should probably be reverting
r238692 instead, but this is hard to do with the number of follow ups
that have happened since. It can't be any worse than the undefined
behaviour that was happening before though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240526 91177308-0d34-0410-b5e6-96231b3b80d8
This allOnes function hits undefined behaviour if Count is greater
than 64, but we can avoid that and simplify the calculation by just
saturating if such a value is passed in.
This comes up under ubsan becauseRxSBGOperands is sometimes created
with values that are 128 bits wide. Somebody more familiar with this
code should probably look into whether that's expected, as a 64 bit
mask may or may not be appropriate for such types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240520 91177308-0d34-0410-b5e6-96231b3b80d8
We used to erroneously match:
(v4i64 shuffle (v2i64 load), <0,0,0,0>)
Whereas vbroadcasti128 is more like:
(v4i64 shuffle (v2i64 load), <0,1,0,1>)
This problem doesn't exist for vbroadcastf128, which kept matching
the intrinsic after r231182. We should perhaps re-introduce the
intrinsic here as well, but that's a separate issue still being
discussed.
While there, add some proper vbroadcastf128 tests. We don't currently
match those, like for loading vbroadcastsd/ss on AVX (the reg-reg
broadcasts where added in AVX2).
Fixes PR23886.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240488 91177308-0d34-0410-b5e6-96231b3b80d8
The only caller of this method is Value::replaceAllUsesWith which
explicitly checks that we are not a GlobalValue. So replace the
body with an unreachable to ensure that we never call it.
The unreachable itself is moved to GlobalValue not GlobalVariable
as that is the base class of all the globals we don't want to call
this method on.
Note, this patch is short lived as i'll soon refactor all callers
of this method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240486 91177308-0d34-0410-b5e6-96231b3b80d8
This commit translates the source locations for MIParser diagnostics from
the locations in the machine instruction string to the locations in the
MIR file.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10574
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240474 91177308-0d34-0410-b5e6-96231b3b80d8
This reorganizes destroyConstant and destroyConstantImpl.
Now there is only destroyConstant in Constant itself, while
subclasses are required to implement destroyConstantImpl.
destroyConstantImpl no longer calls delete but is instead only
responsible for removing the constant from any maps in which it
is contained.
Reviewed by Duncan Exon Smith.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240471 91177308-0d34-0410-b5e6-96231b3b80d8
Currently some users of this function do this explicitly, and all the
rest forget to do this.
ThreadSanitizer was one of such users, and had missing debug
locations for calls into TSan runtime handling atomic operations,
eventually leading to poorly symbolized stack traces and malfunctioning
suppressions.
This is another change relevant to PR23837.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240460 91177308-0d34-0410-b5e6-96231b3b80d8
Change 1: Unswitching on trivial conditions should always happen regardless of the computed unswitching cost, as really the cost is zero. While there is code to make that happen, the logic that checks the unswitching cost against a threshold was moved to an earlier point (revision 147935) than the point where trivial unswitching is detected, so trivial unswitching is currently blocked by the cost threshold. This change fixes that.
Change 2: Before revision 147935 (from 2012-01-11), the threshold parameter was a per-loop threshold. So an unswitching happened only if the cost of the unswitching was less than the threshold. In an indirect way (and I believe unintentionally), the logic for this since then has been that the threshold is an over-all budget across all loops for all loop unswitching done by a given LoopUnswitch loop pass object. So if an unswitching with cost 100 happens in one function, that in effect reduces the threshold from 100 to 0 for the loops even in another function. This persists for the lifetime of that loop pass object. This makes no difference for most small examples but it is important for large examples. This revision fixes that.
Change 3: The cost is currently calculated as std::min(NumInstructions, 5 * NumBlocks). So a loop with 2 blocks and a million instructions will have an unswitching cost of 10. I changed this to just NumInstructions, as it were before revision 147935, though I'm open to e.g. instead replacing std::min with std::max.
I've tried to make the change minimally invasive while staying with what I think was the original intent of the code.
Submitted on behalf of broune@.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240438 91177308-0d34-0410-b5e6-96231b3b80d8
This commit moves the APSInt initialization code that's used by
the LLLexer class into a new APSInt constructor that constructs
APSInts from strings.
This change is useful for MIR Serialization, as it would allow
the MILexer class to use the same APSInt initialization as
LLexer when parsing immediate machine operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240436 91177308-0d34-0410-b5e6-96231b3b80d8
This commit creates a new structure called 'SlotMapping' in the AsmParser library.
This structure can be passed into the public parsing APIs from the AsmParser library
in order to extract the data structures that map from slot numbers to unnamed global
values and metadata nodes.
This change is useful for MIR Serialization, as the MIR Parser has to lookup the
unnamed global values and metadata nodes by their slot numbers.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10551
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240427 91177308-0d34-0410-b5e6-96231b3b80d8
This commit introduces functionality that's used to serialize machine operands.
Only the physical register operands are serialized by this commit.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10525
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240425 91177308-0d34-0410-b5e6-96231b3b80d8
When UpdateBaseRegUses sees an instruction that defines the base
register it must stop, as the base register value it is updating is no
longer live. Ideally we would already have seen the register be killed
(which is already checked for), but the kill flags may be inaccurate
and we have to account for this.
Differential Revision: http://reviews.llvm.org/D10566
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240424 91177308-0d34-0410-b5e6-96231b3b80d8
The class has a non-trivial dtor so we have to clean up before we move
in new members. Remove misleading comment as a default move assignment
operator will never be synthesized for this class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240417 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This only adds support for ULHU of an immediate address with/without a source register.
It does not include support for ULHU of the address of a symbol.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9671
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240410 91177308-0d34-0410-b5e6-96231b3b80d8
So far, LLVM has not emitted correct addend for N64 and N32 ABI. This patch
fixes that. It also removes fixup from MCJIT for R_MIPS_PC16 relocation.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D10565
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240404 91177308-0d34-0410-b5e6-96231b3b80d8
The summary is that it moves the mangling earlier and replaces a few
calls to .addExternalSymbol with addSym.
I originally wanted to replace all the uses of addExternalSymbol with
addSym, but noticed it was a lot of work and doesn't need to be done
all at once.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240395 91177308-0d34-0410-b5e6-96231b3b80d8
This causes errors like:
ld: error: blah.o: requires dynamic R_X86_64_PC32 reloc against '' which
may overflow at runtime; recompile with -fPIC
blah.cc:function f(): error: undefined reference to ''
blah.o:g(): error: undefined reference to ''
I have not yet come up with an appropriate reproduction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240394 91177308-0d34-0410-b5e6-96231b3b80d8
We hit undefined behaviour in some MCExpr tests when the LHS of a left
shift is -1. Twos-complement semantics are completely reasonable here,
so we should just do the shift in unsigned.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240385 91177308-0d34-0410-b5e6-96231b3b80d8
Avoid shifting a negative value by sign-extending after the shift.
Fixes a couple of tests that were failing under ubsan.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240381 91177308-0d34-0410-b5e6-96231b3b80d8