We still don't really have an equivalent of "AssertXExt" in DAG, so we don't
exploit the guarantees on the receiving side yet, but this should produce
conservatively correct code on iOS ABIs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282069 91177308-0d34-0410-b5e6-96231b3b80d8
The only implementation that exists immediately looks it up anyway, and the
information is needed to handle various parameter attributes (stored on the
function itself).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282068 91177308-0d34-0410-b5e6-96231b3b80d8
TargetMachine::getNameWithPrefix and inline the result into the singular
caller." and "Remove more guts of TargetMachine::getNameWithPrefix and
migrate one check to the TLOF mach-o version." temporarily until I can
get the whole call migrated out of the TargetMachine as we could hit
places where TLOF isn't valid.
This reverts commits r281981 and r281983.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282028 91177308-0d34-0410-b5e6-96231b3b80d8
This check caused us to skip adding layout information for calls to
alloca in sspreq/sspstrong mode. We check properly for sspstrong later
on (and add the correct layout info when doing so), so removing this
shouldn't hurt.
No test is included, since testing this using lit seems to require
checking for exact offsets in asm, which is something that the lit tests
for this avoid. If someone cares deeply, I'm happy to write a unittest
or something to cover this, but that feels like overkill.
Patch by Daniel Micay.
Differential Revision: https://reviews.llvm.org/D22714
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282022 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, such section would be marked as SHT_PROGBITS which
makes it impossible to use an initialized C variable declaration
to emit an (allocated) ELF note. The new behavior is also consistent
with ELF assembly parser.
Differential Revision: https://reviews.llvm.org/D24692
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282010 91177308-0d34-0410-b5e6-96231b3b80d8
CodeView has an S_COMPILE3 record to identify the compiler and source language of the compiland. This record comes first in the debug$S section for the compiland. The debuggers rely on this record to know the source language of the code.
There was a little test fallout from introducing a new record into the symbols subsection.
Differential Revision: https://reviews.llvm.org/D24317
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281990 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281977 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281916 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281914 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281852 91177308-0d34-0410-b5e6-96231b3b80d8
It is a trivial change which could make the testcase easier to be reused
for the store splitting in CodeGenPrepare.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281846 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281813 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281784 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281783 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281782 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281727 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281599 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281597 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281532 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281474 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281402 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281362 91177308-0d34-0410-b5e6-96231b3b80d8
Fix failure to detect out of range shift constants leading to assert in ConstantSDNode::getZExtValue()
Followup to D23007
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281354 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281284 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281283 91177308-0d34-0410-b5e6-96231b3b80d8
Tim Northover