| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
This provides a place to add customized operation cost information and
control some other target-specific IR-level transformations.
The only non-trivial logic in this checkin assigns a higher cost to
unaligned loads and stores (covered by the included test case).
llvm-svn: 173520
|
| |
|
|
| |
llvm-svn: 173518
|
| |
|
|
|
|
| |
and, in the case of ELF files, using symbol addresses when available for relocations to the .debug_info section. Also extending the llvm-rtdyld tool to add the ability to dump line number information for testing purposes.
llvm-svn: 173517
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(defined by the x32 ABI) mode, in which case its pointers are 32-bits
in size. This knowledge is also added to X86RegisterInfo that now
returns the appropriate registers in getPointerRegClass.
There are many outcomes to this change. In order to keep the patches
separate and manageable, we start by focusing on some simple testable
cases. The patch adds a test with passing a pointer to a function -
focusing on the difference between the two data models for x86-64.
Another test is added for handling of 'sret' arguments (and
functionality is added in X86ISelLowering to make it work).
A note on naming: the "x32 ABI" document refers to the AMD64
architecture (in LLVM it's distinguished by being is64Bits() in the
x86 subtarget) with two variations: the LP64 (default) data model, and
the ILP32 data model. This patch adds predicates to the subtarget
which are consistent with this naming scheme.
llvm-svn: 173503
|
| |
|
|
| |
llvm-svn: 173501
|
| |
|
|
|
|
| |
duplication.
llvm-svn: 173500
|
| |
|
|
| |
llvm-svn: 173499
|
| |
|
|
| |
llvm-svn: 173497
|
| |
|
|
|
|
| |
AttributeWithIndex.
llvm-svn: 173495
|
| |
|
|
| |
llvm-svn: 173494
|
| |
|
|
|
|
|
|
| |
The order in which operands appear in the encoded instruction is different
to order in which they appear in assembly. This changes the XCore backend to
use the instruction encoding order.
llvm-svn: 173493
|
| |
|
|
|
|
|
|
|
| |
politely report it instead of running into llvm_unreachable.
Also patch llvm-dwarfdump to actually check whether the file it's attempting to
dump is a valid object file.
llvm-svn: 173489
|
| |
|
|
|
|
|
| |
Flags for dumping specific DWARF sections added in lib/DebugInfo and
llvm-dwarfdump.
llvm-svn: 173480
|
| |
|
|
| |
llvm-svn: 173479
|
| |
|
|
|
|
|
| |
With this change the operands order matches the order in which the operands
are encoded in the instruction.
llvm-svn: 173477
|
| |
|
|
| |
llvm-svn: 173476
|
| |
|
|
| |
llvm-svn: 173475
|
| |
|
|
|
|
| |
created InternalizePass (useful for pass reuse)
llvm-svn: 173474
|
| |
|
|
| |
llvm-svn: 173471
|
| |
|
|
| |
llvm-svn: 173467
|
| |
|
|
|
|
|
|
| |
smaller type.
Fixes PR15054.
llvm-svn: 173459
|
| |
|
|
| |
llvm-svn: 173454
|
| |
|
|
| |
llvm-svn: 173453
|
| |
|
|
|
|
|
|
| |
Only for integers, pointers, and vectors of those. No floats.
Instrumentation seems very heavy, and may need to be replaced
with some approximation in the future.
llvm-svn: 173452
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
with an initial number of elements, instead of DenseMap, which has
zero initial elements, in order to avoid the copying of elements
when the size changes and to avoid allocating space every time
LegalizeTypes is run. This patch will not affect the memory footprint,
because DenseMap will increase the element size to 64
when the first element is added.
Patch by Wan Xiaofei.
llvm-svn: 173448
|
| |
|
|
|
|
|
| |
Uses the new !add TableGen operator to do more cleanup of the
PPC register definitions.
llvm-svn: 173446
|
| |
|
|
|
|
|
| |
This adds an !add(a, b) operator to tablegen; this will be used
to cleanup the PPC register definitions.
llvm-svn: 173445
|
| |
|
|
|
|
| |
If the sutraction of the higher 32 bit parts gives a 0 result, we need to do the store operation.
llvm-svn: 173437
|
| |
|
|
| |
llvm-svn: 173434
|
| |
|
|
| |
llvm-svn: 173433
|
| |
|
|
| |
llvm-svn: 173432
|
| |
|
|
| |
llvm-svn: 173431
|
| |
|
|
|
|
| |
This fixes DAG subtree analysis at the boundary.
llvm-svn: 173427
|
| |
|
|
|
|
|
|
|
| |
Maintain separate per-node and per-tree book-keeping.
Track all instructions above a DAG node including nested subtrees.
Seperately track instructions within a subtree.
Record subtree parents.
llvm-svn: 173426
|
| |
|
|
|
|
|
| |
Allow the strategy to select SchedDFS. Allow the results of SchedDFS
to affect initialization of the scheduler state.
llvm-svn: 173425
|
| |
|
|
|
|
|
| |
This is mostly refactoring, along with adding an instruction count
within the subtrees and ensuring we only look at data edges.
llvm-svn: 173420
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loops over instructions in the basic block or the use-def list of the
value, neither of which are really efficient when repeatedly querying
about values in the same basic block.
What's more, we already know that the CondBB is small, and so we can do
a much more efficient test by counting the uses in CondBB, and seeing if
those account for all of the uses.
Finally, we shouldn't blanket fail on any such instruction, instead we
should conservatively assume that those instructions are part of the
cost.
Note that this actually fixes a bug in the pass because
isUsedInBasicBlock has a really terrible bug in it. I'll fix that in my
next commit, but the fix for it would make this code suddenly take the
compile time hit I thought it already was taking, so I wanted to go
ahead and migrate this code to a faster & better pattern.
The bug in isUsedInBasicBlock was also causing other tests to test the
wrong thing entirely: for example we weren't actually disabling
speculation for floating point operations as intended (and tested), but
the test passed because we failed to speculate them due to the
isUsedInBasicBlock failure.
llvm-svn: 173417
|
| |
|
|
|
|
| |
interface and allow other strategies to select it.
llvm-svn: 173413
|
| |
|
|
|
|
|
|
| |
directive for the Mips assembler.
Contributer: Vladimir Medic
llvm-svn: 173407
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 173401
|
| |
|
|
|
|
|
|
|
|
| |
For sanity, create a root when NumDataSuccs >= 4. Splitting large
subtrees will no longer be detrimental after my next checkin to handle
nested tree. A magic number of 4 is fine because single subtrees
seldom rejoin more than this. It makes subtrees easier to visualize
and heuristics more sane.
llvm-svn: 173399
|
| |
|
|
|
|
| |
Patch by Stefan Hepp.
llvm-svn: 173395
|
| |
|
|
| |
llvm-svn: 173382
|
| |
|
|
|
|
| |
in 'Provenance Analysis'.
llvm-svn: 173374
|
| |
|
|
|
|
|
|
|
|
|
| |
No functionality change intended.
This captures the first two cases GPR32/64. For the others, we need
an addition operator (if we have one, I've not yet found it).
Based on a suggestion made by Tom Stellard in the AArch64 review!
llvm-svn: 173366
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Plug TTI into the speculation logic, giving it a real cost interface
that can be specialized by targets.
The goal here is not to be more aggressive, but to just be more accurate
with very obvious cases. There are instructions which are known to be
truly free and which were not being modeled as such in this code -- see
the regression test which is distilled from an inner loop of zlib.
Everywhere the TTI cost model is insufficiently conservative I've added
explicit checks with FIXME comments to go add proper modelling of these
cost factors.
If this causes regressions, the likely solution is to make TTI even more
conservative in its cost estimates, but test cases will help here.
llvm-svn: 173357
|
| |
|
|
|
|
|
|
|
|
| |
We use constant folding to see if an intrinsic evaluates to the same value as a
constant that we know. If we don't take the undefinedness into account we get a
value that doesn't match the actual implementation, and miscompiled code.
This was uncovered by Chandler's simplifycfg changes.
llvm-svn: 173356
|
| |
|
|
|
|
| |
of stage2 in a bootstrap. Still investigating....
llvm-svn: 173343
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that can be specialized by targets.
The goal here is not to be more aggressive, but to just be more accurate
with very obvious cases. There are instructions which are known to be
truly free and which were not being modeled as such in this code -- see
the regression test which is distilled from an inner loop of zlib.
Everywhere the TTI cost model is insufficiently conservative I've added
explicit checks with FIXME comments to go add proper modelling of these
cost factors.
If this causes regressions, the likely solution is to make TTI even more
conservative in its cost estimates, but test cases will help here.
llvm-svn: 173342
|
| |
|
|
|
|
|
| |
unfolded constant expressions rather than checking each one
independently.
llvm-svn: 173341
|