|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| | llvm-svn: 231122 | 
| | 
| 
| 
| 
| 
| 
| 
| | frame register before checking if there is a DWARF register number for it.
Thanks to H.J. Lu for diagnosing this and providing the testcase!
llvm-svn: 231121 | 
| | 
| 
| 
| 
| 
| | Differential Revision: http://reviews.llvm.org/D7865
llvm-svn: 231117 | 
| | 
| 
| 
| 
| 
| | where it is so that future generations can understand.
llvm-svn: 231111 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The cause of the issue is the interaction of two factors:
1) When generating a DW_TAG_imported_declaration DIE which imports another 
   imported declaration, the code in AsmPrinter/DwarfCompileUnit.cpp 
   asserts that the second imported declaration must already have a DIE.
2) There is a non-determinism in the order in which imported declarations
   within the same scope are processed.
Because of the non-determinism (2), it is possible that an imported 
declaration is processed before another one it depends on, breaking the 
assumption in (1).
The source of the non-determinism is that the imported declaration 
DIDescriptors are sorted by scope in DwarfDebug::beginModule(); however that
sort is not a stable_sort, therefore the order of the declarations within 
the same scope is not preserved. The attached patch changes the std::sort to
a std::stable_sort and it fixes the problem.
Test omitted due to it being non-deterministic and depending on the
implementation of std::sort.
llvm-svn: 231100 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This prevents the behavior observed in llvm.org/PR22369. I am not sure
whether I am reading the code correctly, but the early exit based on
isLiveOutPastPHIs() seems to make the wrong assumption that
RegisterCoalescer won't be able to coalesce those copies later.
This change hides the new behavior behind -no-phi-elim-live-out-early-exit
as it currently breaks four tests:
 * Assertion in:
     CodeGen/Hexagon/hwloop-cleanup.ll
 * Worse code in:
     CodeGen/X86/coalescer-commute4.ll
     CodeGen/X86/phys_subreg_coalesce-2.ll
     CodeGen/X86/zlib-longest-match.ll
   The root cause here seems to be that the heuristic that determines
   the visitation order in RegisterCoalescer gets less lucky.
llvm-svn: 231064 | 
| | 
| 
| 
| 
| 
| | Differential Revision: http://reviews.llvm.org/D7844
llvm-svn: 231042 | 
| | 
| 
| 
| 
| 
| 
| 
| | current""
This reapplies r230990 without modifications.
llvm-svn: 231024 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | TargetRegisterInfo. DebugLocEntry now holds a buffer with the raw bytes
of the pre-calculated DWARF expression.
Ought to be NFC, but it does slightly alter the output format of the
textual assembly.
This reapplies 230930 without the assertion in DebugLocEntry::finalize()
because not all Machine registers can be lowered into DWARF register
numbers and floating point constants cannot be expressed.
llvm-svn: 231023 | 
| | 
| 
| 
| 
| 
| | *reinterpret_cast<u{little,big}{16,32,64}_t>().
llvm-svn: 231016 | 
| | 
| 
| 
| 
| 
| | This reverts commit 230975 to investigate buildbot breakage.
llvm-svn: 231004 | 
| | 
| 
| 
| 
| 
| | This reverts commit 230990 because also reverting 230975.
llvm-svn: 231003 | 
| | 
| 
| 
| 
| 
| | MachineFunction.
llvm-svn: 230990 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | TargetRegisterInfo. DebugLocEntry now holds a buffer with the raw bytes
of the pre-calculated DWARF expression.
Ought to be NFC, but it does slightly alter the output format of the
textual assembly.
This reapplies 230930 with a relaxed assertion in DebugLocEntry::finalize()
that allows for empty DWARF expressions for constant FP values.
llvm-svn: 230975 | 
| | 
| 
| 
| | llvm-svn: 230973 | 
| | 
| 
| 
| | llvm-svn: 230972 | 
| | 
| 
| 
| | llvm-svn: 230948 | 
| | 
| 
| 
| | llvm-svn: 230932 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | TargetRegisterInfo. DebugLocEntry now holds a buffer with the raw bytes
of the pre-calculated DWARF expression.
Ought to be NFC, but it does slightly alter the output format of the
textual assembly.
llvm-svn: 230930 | 
| | 
| 
| 
| 
| 
| | Thanks David !
llvm-svn: 230908 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Such edges are zero matrix, and they bring no additional info to the
allocation problem, apart from contributing to nodes' degree. Removing
those edges is expected to improve allocation time.
Tune the spill cost comparison, as this gives better average performances
now that the nodes' degrees has changed.
llvm-svn: 230904 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | We were missing a check for the following fold in DAGCombiner:
// fold (fmul (fmul x, c1), c2) -> (fmul x, (fmul c1, c2))
If 'x' is also a constant, then we shouldn't do anything. Otherwise, we could end up swapping the operands back and forth forever.
This should fix:
http://llvm.org/bugs/show_bug.cgi?id=22698
Differential Revision: http://reviews.llvm.org/D7917
llvm-svn: 230884 | 
| | 
| 
| 
| 
| 
| | the precise number
llvm-svn: 230865 | 
| | 
| 
| 
| | llvm-svn: 230864 | 
| | 
| 
| 
| 
| 
| 
| | I didn't see this so far because it scans backwards, but that doesn't
make it any less quadratic. NFC.
llvm-svn: 230863 | 
| | 
| 
| 
| 
| 
| 
| 
| | Level 1 should abort for all instructions but call/terminators/args.
Instead it was aborting only if the level was > 2
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 230861 | 
| | 
| 
| 
| 
| 
| | No functionality change intended.
llvm-svn: 230849 | 
| | 
| 
| 
| | llvm-svn: 230846 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | All of the cases were just appending from random access iterators to a
vector. Using insert/append can grow the vector to the perfect size
directly and moves the growing out of the loop. No intended functionalty
change.
llvm-svn: 230845 | 
| | 
| 
| 
| 
| 
| 
| | It's too big for inlining anyways. Also clean it up slightly. No functionality
change intended.
llvm-svn: 230806 | 
| | 
| 
| 
| | llvm-svn: 230798 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This work is currently being rethought along different lines and
if this work is needed it can be resurrected out of svn. Remove it
for now as no current work in ongoing on it and it's unused. Verified
with the authors before removal.
llvm-svn: 230780 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Currently fast-isel-abort will only abort for regular instructions,
and just warn for function calls, terminators, function arguments.
There is already fast-isel-abort-args but nothing for calls and
terminators.
This change turns the fast-isel-abort options into an integer option,
so that multiple levels of strictness can be defined.
This will help no being surprised when the "abort" option indeed does
not abort, and enables the possibility to write test that verifies
that no intrinsics are forgotten by fast-isel.
Reviewers: resistor, echristo
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D7941
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 230775 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This removes a bit of duplicated code and more importantly, remembers the
labels so that they don't need to be looked up by name.
This in turn allows for any name to be used and avoids a crash if the name
we wanted was already taken.
llvm-svn: 230772 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | that is iterating over it
Inserting elements into a `DenseMap` invalidated iterators pointing
into the `DenseMap` instance.
Differential Revision: http://reviews.llvm.org/D7924
llvm-svn: 230719 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | uses of TM->getSubtargetImpl and propagate to all calls.
This could be a debugging regression in places where we had a
TargetMachine and/or MachineFunction but don't have it as part
of the MachineInstr. Fixing this would require passing a
MachineFunction/Function down through the print operator, but
none of the existing uses in tree seem to do this.
llvm-svn: 230710 | 
| | 
| 
| 
| 
| 
| 
| | A small regression in r230411 was that we were basing the decision on
-fdata-sections.
llvm-svn: 230707 | 
| | 
| 
| 
| 
| 
| | forwarding to the one that didn't take a context.
llvm-svn: 230700 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | a lookup, pass that in rather than use a naked call to getSubtargetImpl.
This involved passing down and around either a TargetMachine or
TargetRegisterInfo. Update all callers/definitions around the targets
and SelectionDAG.
llvm-svn: 230699 | 
| | 
| 
| 
| 
| 
| 
| | need this shortly to get a TargetRegisterInfo from the subtarget
for TargetLowering routines.
llvm-svn: 230698 | 
| | 
| 
| 
| 
| 
| 
| | Move SectionMap to its only user (emitDebugARanges) and
reorder to save a call to sort.
llvm-svn: 230693 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | have the debugger step through each one individually. Turn off the
combine for adjacent stores at -O0 so we get this behavior.
Possibly, DAGCombine shouldn't run at all at -O0, but that's for
another day; see PR22346.
Differential Revision: http://reviews.llvm.org/D7181
llvm-svn: 230659 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This required plumbing a TargetRegisterInfo through computeRegisterProperties
and into findRepresentativeClass which uses it for register class
iteration. This required passing a subtarget into a few target specific
initializations of TargetLowering.
llvm-svn: 230583 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | the .h file. It's used in only one place (other than recursively)
and there's no need to include it everywhere.
Saves almost 900k from total llvm object file size.
llvm-svn: 230561 | 
| | 
| 
| 
| | llvm-svn: 230535 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This patch unifies the comdat and non-comdat code paths. By doing this
it add missing features to the comdat side and removes the fixed
section assumptions from the non-comdat side.
In ELF there is no one true section for "4 byte mergeable" constants.
We are better off computing the required properties of the section
and asking the context for it.
llvm-svn: 230411 | 
| | 
| 
| 
| 
| 
| 
| | There is no need to open-code the alignment calculation, we have a
handy RoundUpToAlignment function which "Does The Right Thing (TM)".
llvm-svn: 230392 | 
| | 
| 
| 
| 
| 
| | the smallest build vector input scalar type is always used. Additional (crash) test cases already committed.
llvm-svn: 230388 | 
| | 
| 
| 
| | llvm-svn: 230378 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Author: Simon Pilgrim <llvm-dev@redking.me.uk>
Date:   Mon Feb 23 23:04:28 2015 +0000
    Fix based on post-commit comment on D7816 & rL230177 - BUILD_VECTOR operand truncation was using the the BV's output scalar type instead of the input type.
and
Author: Simon Pilgrim <llvm-dev@redking.me.uk>
Date:   Sun Feb 22 18:17:28 2015 +0000
    [DagCombiner] Generalized BuildVector Vector Concatenation
    The CONCAT_VECTORS combiner pass can transform the concat of two BUILD_VECTOR nodes into a single BUILD_VECTOR node.
    This patch generalises this to support any number of BUILD_VECTOR nodes, and also permits UNDEF nodes to be included as well.
    This was noticed as AVX vec128 -> vec256 canonicalization sometimes creates a CONCAT_VECTOR with a real vec128 lower and an vec128 UNDEF upper.
    Differential Revision: http://reviews.llvm.org/D7816
as the root cause of PR22678 which is causing an assertion inside the DAG combiner.
I'll follow up to the main thread as well.
llvm-svn: 230358 |