| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
to the TLOF mach-o version.
NFC intended.
llvm-svn: 281983
|
|
|
|
|
|
| |
inline the result into the singular caller.
llvm-svn: 281981
|
|
|
|
|
|
| |
Include header messages and remove unnecessary blank lines.
llvm-svn: 281980
|
|
|
|
|
|
|
|
|
|
|
| |
This should match the existing behaviour for passing complicated struct and
array types, in particular HFAs come through like that from Clang.
For C & C++ we still need to somehow support all the weird ABI flags, or at
least those that are present in the IR (signext, byval, ...), and stack-based
parameter passing.
llvm-svn: 281977
|
|
|
|
|
|
|
|
|
|
| |
It is legal to merge instructions with different undef flags; However we
must drop the undef flag from the merged instruction if it isn't present
everywhere.
This fixes http://llvm.org/PR30199
llvm-svn: 281957
|
|
|
|
|
|
| |
This was meant to be commited with my previous commit.
llvm-svn: 281948
|
|
|
|
|
|
|
|
|
|
|
| |
The OperandsMapper class is used heavy in RegBankSelect and each
instantiation triggered a heap allocation for the array of operands.
Instead, use a SmallVector with a big enough size such that most of the
cases do not have to use dynamically allocated memory.
This improves the compile time of the RegBankSelect pass.
llvm-svn: 281916
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Machine programs need a definition of each vreg before reaching a use
(the definition may come from an IMPLICIT_DEF instruction). This class
of errors is not detected by the MachineVerifier because of efficiency
concerns. LiveRangeCalc used to report these problems, make it do that
again (followup to r279625).
Also use report_fatal_error() instead of llvm_unreachable() as the error
reporting is only present in asserts build anyway.
llvm-svn: 281914
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a port of XRay to ARM 32-bit, without Thumb support yet. The XRay instrumentation support is moving up to AsmPrinter.
This is one of 3 commits to different repositories of XRay ARM port. The other 2 are:
https://reviews.llvm.org/D23932 (Clang test)
https://reviews.llvm.org/D23933 (compiler-rt)
Differential Revision: https://reviews.llvm.org/D23931
llvm-svn: 281878
|
|
|
|
|
|
|
|
| |
rounding mode encoding in the second operand. This immediate should only be 0 or 1 and indicates if the truncation loses precision.
Also enhance an assert in SelectionDAG::getNode to flag this sort of problem in the future.
llvm-svn: 281868
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as sitofp
With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations.
This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware).
While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions.
Differential Revision: https://reviews.llvm.org/D24343
llvm-svn: 281852
|
|
|
|
|
|
|
| |
It is a trivial change which could make the testcase easier to be reused
for the store splitting in CodeGenPrepare.
llvm-svn: 281846
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
names (NFC)
The ValueSymbolTable is used to detect name conflict and rename
instructions automatically. This is not needed when the value
names are automatically discarded by the LLVMContext.
No functional change intended, just saving a little bit of memory.
This is a recommit of r281806 after fixing the accessor to return
a pointer instead of a reference and updating all the call-sites.
llvm-svn: 281813
|
|
|
|
|
|
| |
Last-second refactoring before push was bad idea...
llvm-svn: 281812
|
|
|
|
|
|
| |
This is in line with the LLParser behavior
llvm-svn: 281811
|
|
|
|
|
|
|
|
|
|
| |
This is a fix for PR30318.
Clang may generate IR where an alloca is already live when entering a
BB with lifetime.start. In this case, conservatively extend the
alloca lifetime all the way back to the block entry.
llvm-svn: 281784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When trying to recolor a register we may split live-ranges in the
process. When we create new live-ranges we will have to process them,
but when we move a register from Assign to Split, the allocation is not
changed until the whole recoloring session is successful.
Therefore, only push the live-ranges that changed from Assign to
Split when the recoloring is successful.
Same as the previous commit, I was not able to produce a test case that
reproduce the problem with in-tree targets.
Note: The bug has been here since the recoloring scheme has been added
back in r200883 (Feb 2014).
llvm-svn: 281783
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is used.
When last chance recoloring is used, the list of NewVRegs may not be
empty when calling selectOrSplitImpl. Indeed, another coloring may have
taken place with splitting/spilling in the same recoloring session.
Relax an assertion to take this into account and adapt a condition to
act as if the NewVRegs were local to this selectOrSplitImpl instance.
Unfortunately I am unable to produce a test case for this, I was only
able to reproduce the conditions on an out-of-tree target.
llvm-svn: 281782
|
|
|
|
|
|
|
| |
Also relax a RegisterBankInfo verifier check that's incompatible with
1-bit mappings.
llvm-svn: 281735
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a phi node is finally lowered to a machine instruction it is
important that the lowered "load" instruction is placed before the
associated DEBUG_VALUE entry describing the value loaded.
Renamed the existing SkipPHIsAndLabels to SkipPHIsLabelsAndDebug to
more fully describe that it also skips debug entries. Then used the
"new" function SkipPHIsAndLabels when the debug information should not
be skipped when placing the lowered "load" instructions so that it is
placed before the debug entries.
Differential Revision: https://reviews.llvm.org/D23760
llvm-svn: 281727
|
|
|
|
|
|
| |
TLOF API accordingly.
llvm-svn: 281708
|
|
|
|
| |
llvm-svn: 281602
|
|
|
|
| |
llvm-svn: 281600
|
|
|
|
|
|
|
|
| |
It was only really there as a sentinel when instructions had to have precisely
one type. Now that registers are typed, each register really has to have a type
that is sized.
llvm-svn: 281599
|
|
|
|
|
|
|
| |
Otherwise everything that needs to work out what size they are has to keep a
DataLayout handy, which is a bit silly and very annoying.
llvm-svn: 281597
|
|
|
|
| |
llvm-svn: 281542
|
|
|
|
| |
llvm-svn: 281535
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It was previously not possible for tools to use solely the stackmap
information emitted to reconstruct the return addresses of callsites in
the map, which is necessary to use the information to walk a stack. This
patch adds per-function callsite counts when emitting the stackmap
section in order to resolve the problem. Note that this slightly alters
the stackmap format, so external tools parsing these maps will need to
be updated.
**Problem Details:**
Records only store their offset from the beginning of the function they
belong to. While these records and the functions are output in program
order, it is not possible to determine where the end of one function's
records are without the callsite count when processing the records to
compute return addresses.
Patch by Kavon Farvardin!
Reviewers: atrick, ributzka, sanjoy
Subscribers: nemanjai
Differential Revision: https://reviews.llvm.org/D23487
llvm-svn: 281532
|
|
|
|
|
|
|
| |
analyzeBranch was renamed to use lowercase first, rename
the related set to match.
llvm-svn: 281506
|
|
|
|
|
|
| |
; NFCI
llvm-svn: 281498
|
|
|
|
| |
llvm-svn: 281495
|
|
|
|
| |
llvm-svn: 281493
|
|
|
|
| |
llvm-svn: 281490
|
|
|
|
| |
llvm-svn: 281489
|
|
|
|
|
|
|
|
|
|
| |
in order to make sure that its TargetMachine constructor is
registered.
This allows us to run the PEI machine pass with MIR input
(see PR30324).
llvm-svn: 281474
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When expanding mul in type legalization make sure the type for shift amount can actually fit the value. This fixes PR30354 https://llvm.org/bugs/show_bug.cgi?id=30354.
Reviewers: hfinkel, majnemer, RKSimon
Subscribers: RKSimon, llvm-commits
Differential Revision: https://reviews.llvm.org/D24478
llvm-svn: 281403
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to, in some cases, create a vector_shuffle out of a build_vector, when
the inputs to the build are extract_elements from two different vectors, at least one
of which is wider than the output. (E.g. a <8 x i16> being constructed out of
elements from a <16 x i16> and a <8 x i16>).
Differential Revision: https://reviews.llvm.org/D24491
llvm-svn: 281402
|
|
|
|
| |
llvm-svn: 281369
|
|
|
|
|
|
|
|
|
|
| |
test
To avoid assertion, we must ensure that the inner shift constant is within range before calling ConstantSDNode::getZExtValue(). We already know that the outer shift constant is in range.
Followup to D23007
llvm-svn: 281362
|
|
|
|
|
|
|
|
| |
Fix failure to detect out of range shift constants leading to assert in ConstantSDNode::getZExtValue()
Followup to D23007
llvm-svn: 281354
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23764
llvm-svn: 281308
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch reverses the edge from DIGlobalVariable to GlobalVariable.
This will allow us to more easily preserve debug info metadata when
manipulating global variables.
Fixes PR30362. A program for upgrading test cases is attached to that
bug.
Differential Revision: http://reviews.llvm.org/D20147
llvm-svn: 281284
|
|
|
|
|
|
|
| |
This should make it easier to add cases that we currently don't cover,
like supporting more kinds of type mismatches and more than 2 input vectors.
llvm-svn: 281283
|
|
|
|
| |
llvm-svn: 281253
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: If consecutive select instructions are lowered separately in CGP, it will introduce redundant condition check and branches that cannot be removed by later optimization phases. This patch lowers all consecutive select instructions at the same to to avoid inefficent code as demonstrated in https://llvm.org/bugs/show_bug.cgi?id=29095
Reviewers: davidxl
Subscribers: vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D24147
llvm-svn: 281252
|
|
|
|
| |
llvm-svn: 281229
|
|
|
|
|
|
| |
We're not supposed to have duplicate live-ins.
llvm-svn: 281224
|
|
|
|
| |
llvm-svn: 281207
|
|
|
|
|
|
|
|
| |
Unlike SDag, we use a separate G_GEP instruction (much simplified, only taking
a single byte offset) to preserve the pointer type information through
selection.
llvm-svn: 281205
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some generic instructions have multiple types. While in theory these always be
discovered by inspecting the single definition of each generic vreg, in
practice those definitions won't always be local and traipsing through a big
function to find them will not be fun.
So this changes MIRPrinter to print out the type of uses as well as defs, if
they're known to be different or not known to be the same.
On the parsing side, we're a little more flexible: provided each register is
given a type in at least one place it's mentioned (and all types are
consistent) we accept the MIR. This doesn't introduce ambiguity but makes
writing tests manually a bit less painful.
llvm-svn: 281204
|