For instance, following transformation will be disabled:
x + x + x => 3.0f * x;
The problem of these transformations is that it introduces a FP constant, which
following Instruction-Selection pass cannot handle.
Reviewed by Nadav, thanks a lot!
rdar://13445387
llvm-svn: 177933
Performing this check unilaterally prevented us from generating FMAs when the incoming IR contained illegal vector types which would eventually be legalized to underlying types that *did* support FMA.
For example, an @llvm.fmuladd on an OpenCL float16 should become a sequence of float4 FMAs, not float4 fmul+fadd's.
NOTE: Because we still call the target-specific profitability hook, individual targets can reinstate the old behavior, if desired, by simply performing the legality check inside their callback hook. They can also perform more sophisticated legality checks, if, for example, some illegal vector types can be productively implemented as FMAs, but not others.
llvm-svn: 177820
177774 broke the lld-x86_64-darwin11 builder; error:
error: comparison of integers of different signs: 'int' and 'size_type' (aka 'unsigned long')
for (SI = 0; SI < Scavenged.size(); ++SI)
~~ ^ ~~~~~~~~~~~~~~~~
Fix this by making SI also unsigned.
llvm-svn: 177780
This patch lets the register scavenger make use of multiple spill slots in
order to guarantee that it will be able to provide multiple registers
simultaneously.
To support this, the RS's API has changed slightly: setScavengingFrameIndex /
getScavengingFrameIndex have been replaced by addScavengingFrameIndex /
isScavengingFrameIndex / getScavengingFrameIndices.
In forthcoming commits, the PowerPC backend will use this capability in order
to implement the spilling of condition registers, and some special-purpose
registers, without relying on r0 being reserved. In some cases, spilling these
registers requires two GPRs: one for addressing and one to hold the value being
transferred.
llvm-svn: 177774
This reverts commit 06091513c283c863296f01cc7c2e86b56bb50d02.
The code is obviously wrong, but the trivial fix causes
inefficient code generation on X86. Somebody with more
knowledge of the code needs to take a look here.
Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 177529
A node's ordering is only propagated during legalization if (a) the new node does
not have an ordering (is not a CSE'd node), or (b) the new node has an ordering
that is higher than the node being legalized.
llvm-svn: 177465
The linker sorts the .tls$<xyz> sections by name, and we need
to make sure any extra sections we produce (e.g. for weak globals)
always end up between .tls$AAA and .tls$ZZZ, even if the name
starts with e.g. an underscore.
Patch by David Nadlinger!
llvm-svn: 177256
Implicit defs are not currently positional and not modeled by the
per-operand machine model. Unfortunately, we treat defs that are part
of the architectural instruction description, like flags, the same as
other implicit defs. Really, they should have a fixed MachineInstr
layout and probably shouldn't be "implicit" at all.
For now, we'll change the default latency to be the max operand
latency. That will give flag setting operands full latency for x86
folded loads. Other kinds of "fake" implicit defs don't occur prior to
regalloc anyway, and we would like them to go away postRegAlloc as
well.
llvm-svn: 177227
This is a generic function (derived from PEI); moving it into
MachineFrameInfo eliminates a current redundancy between the ARM and AArch64
backends, and will allow it to be used by the PowerPC target code.
No functionality change intended.
llvm-svn: 177111
Add the current PEI register scavenger as a parameter to the
processFunctionBeforeFrameFinalized callback.
This change is necessary in order to allow the PowerPC target code to
set the register scavenger frame index after the save-area offset
adjustments performed by processFunctionBeforeFrameFinalized. Only
after these adjustments have been made is it possible to estimate
the size of the stack frame.
llvm-svn: 177108
This doesn't reset all of the target options within the TargetOptions
object. This is because some of those are ABI-specific and must be determined if
it's okay to change those on the fly.
llvm-svn: 176986
belongs to a different compile unit.
DW_FORM_ref_addr should be used for cross compile-unit reference.
When compiling a large application, we got a dwarfdump verification error where
abstract_origin points to nowhere.
This error can't be reproduced on any testing case in MultiSource.
We may have other cases where we use DW_FORM_ref4 unconditionally.
rdar://problem/13370501
llvm-svn: 176882
Versioned debug info support has been a burden to maintain & also compromised
current debug info verification by causing test cases testing old debug info to
remain rather than being updated to the latest. It also makes it hard to add or
change the metadata schema by requiring various backwards-compatibility in the
DI* hierarchy.
So it's being removed in preparation for new changes to the schema to tidy up
old/unnecessary fields and add new fields needed for new debug info (well, new
to LLVM at least).
The more surprising part of this is the changes to DI*::Verify - this became
necessary due to the changes to AsmWriter. AsmWriter was relying on the version
test to decide which bits of metadata were actually debug info when printing
the comment annotations. Without the version information the tag numbers were
too common & it would print debug info on random metadata that happened to
start with an integer that matched a tag number. Instead this change makes the
Verify functions more precise (just adding "number of operands" checks - not
type checking those operands yet) & relies on that to decide which metadata is
debug info metadata.
llvm-svn: 176838
Summary:
Statistics are still available in Release+Asserts (any +Asserts builds),
and stats can also be turned on with LLVM_ENABLE_STATS.
Move some of the FastISel stats that were moved under DEBUG()
back out of DEBUG(), since stats are disabled across the board now.
Many tests depend on grepping "-stats" output. Move those into
a orig_dir/Stats/. so that they can be marked as unsupported
when building without statistics.
Differential Revision: http://llvm-reviews.chandlerc.com/D486
llvm-svn: 176733
LegalizeDAG.cpp uses the value of the comparison operands when checking
the legality of BR_CC, so DAGCombiner should do the same.
v2:
- Expand more BR_CC value types for NVPTX
v3:
- Expand correct BR_CC value types for Hexagon, Mips, and XCore.
llvm-svn: 176694
This verifies live intervals both before and after scheduling. It's
useful for anyone hacking on live interval update.
Note that we don't yet pass verification all the time. We don't yet
handle updating nonallocatable live intervals perfectly.
llvm-svn: 176685
Code generation makes some basic assumptions about the IR it's been given. In
particular, if there is only one 'invoke' in the function, then that invoke
won't be going away. However, with the advent of the `llvm.donothing' intrinsic,
those invokes may go away. If all of them go away, the landing pad no longer has
any users. This confuses the back-end, which asserts.
This happens with SjLj exceptions, because that's the model that modifies the IR
based on there being invokes, etc. in the function.
Remove any invokes of `llvm.donothing' during SjLj EH preparation. This will
give us a CFG that the back-end won't be confused about. If all of the invokes
in a function are removed, then the SjLj EH prepare pass won't insert the bogus
code the relies upon the invokes being there.
<rdar://problem/13228754&13316637>
llvm-svn: 176677
In very rare cases caused by irreducible control flow, the dominating
block can have the same trace head without actually being part of the
trace.
As long as such a dominator still has valid instruction depths, it is OK
to use it for computing instruction depths.
Rename the function to avoid lying, and add a check that instruction
depths are computed for the dominator.
llvm-svn: 176668
rdar:13370002 [pre-RA-sched] assertion: released too many times
I tracked this down to an earlier hack that is no longer applicable
and interfered with normal scheduler logic. With the changes in
r176037, it was causing an instruction to be scheduled multiple times.
I have an external test case that I tried hard to reduce and
failed. I can't even reproduce with llc.
llvm-svn: 176636
We now emit a line table for each compile unit. To reduce the prologue size
of each line table, the files and directories used by each compile unit are
stored in std::map<unsigned, std::vector< > > instead of std::vector< >.
The prologue for a lto'ed image can be as big as 93K. Duplicating 93K for each
compile unit causes a huge increase of debug info. With this patch, each
prologue will only emit the files required by the compile unit.
rdar://problem/13342023
llvm-svn: 176605
- ISD::SHL/SRL/SRA must have either both scalar or both vector operands
but TLI.getShiftAmountTy() so far only return scalar type. As a
result, backend logic assuming that breaks.
- Rename the original TLI.getShiftAmountTy() to
TLI.getScalarShiftAmountTy() and re-define TLI.getShiftAmountTy() to
return target-specificed scalar type or the same vector type as the
1st operand.
- Fix most TICG logic assuming TLI.getShiftAmountTy() a simple scalar
type.
llvm-svn: 176364
We avoided computing DAG height/depth during Node printing because it
shouldn't depend on an otherwise valid DAG. But this has become far
too annoying for the common case of a valid DAG where we want to see
valid values. If doing the computation on-the-fly turns out to be a
problem in practice, then I'll add a mode to the diagnostics to only
force it when we're likely to have a valid DAG, otherwise explicitly
print INVALID instead of bogus numbers. For now, just go for it all
the time.
llvm-svn: 176314
SelectionDAGIsel::LowerArguments needs a function, not a basic block. So it
makes sense to pass it the function instead of extracting a basic-block from
the function and then tossing it. This is also more self-documenting (functions
have arguments, BBs don't).
In addition, added comments to a couple of Select* methods.
llvm-svn: 176305
We make the cost for calling libm functions extremely high as emitting the
calls is expensive and causes spills (on x86) so performance suffers. We still
vectorize important calls like ceilf and friends on SSE4.1. and fabs.
Differential Revision: http://llvm-reviews.chandlerc.com/D466
llvm-svn: 176287
definition DIE (TAG_variable), and put AT_MIPS_linkage_name to TAG_member when
DarwinGDBCompat is true.
Darwin GDB needs AT_MIPS_linkage_name at both places to work.
Follow-up patch to r176143.
rdar://problem/13291234
llvm-svn: 176220
definition DIE, to make old GDB happy.
We have a regression for old GDB when Clang uses DW_TAG_member to declare
static members inside a class, instead of DW_TAG_variable. This patch will fix
this regression.
rdar://problem/13291234
llvm-svn: 176143
TAG_member inside a class to the specification DIE.
Having AT_MIPS_linkage_name on TAG_member caused old gdb (GNU 6.3.50) to
error out. Also gcc 4.7 has AT_MIPS_linkage_name on the specification DIE.
rdar://problem/13291234
llvm-svn: 176120
fewer scalar integer (i32 or i64) arguments. It completely eliminates the need
for SDISel for trivial functions.
Also, add the new llc -fast-isel-abort-args option, which is similar to
-fast-isel-abort option, but for formal argument lowering.
llvm-svn: 176052
memory intrinsics in the SDAG builder.
When alignment is zero, the lang ref says that *no* alignment
assumptions can be made. This is the exact opposite of the internal API
contracts of the DAG where alignment 0 indicates that the alignment can
be made to be anything desired.
There is another, more explicit alignment that is better suited for the
role of "no alignment at all": an alignment of 1. Map the intrinsic
alignment to this early so that we don't end up generating aligned DAGs.
It is really terrifying that we've never seen this before, but we
suddenly started generating a large number of alignment 0 memcpys due to
the new code to do memcpy-based copying of POD class members. That patch
contains a bug that rounds bitfield alignments down when they are the
first field. This can in turn produce zero alignments.
This fixes weird crashes I've seen in library users of LLVM on 32-bit
hosts, etc.
llvm-svn: 176022
itself recursively with a new instruction that has not been finalized, in order
to determine whether to keep the instruction. On 'make check' and test-suite the
only cases where the recursive invocation made any transformations were simple
instruction commutations, so I am restricting the recursive invocation to do
only this.
The other cases wouldn't work correctly when updating LiveIntervals, since the
new instructions don't have slot indices and LiveIntervals hasn't yet been
updated. If the other transformations were actually triggering in any test case
it would be possible to support it with a lot of effort, but since they don't
it's not worth it.
llvm-svn: 175979
unless it was requested to with an optional parameter that defaults to false, so
we don't need to handle that case in TwoAddressInstructionPass.
llvm-svn: 175974
TwoAddressInstructionPass. The code in rescheduleMIBelowKill() is a bit tricky,
since multiple instructions need to be moved down, one-at-a-time, in reverse
order.
llvm-svn: 175955
One of the phases of SelectionDAG is LegalizeVectors. We don't need to sort the DAG and copy nodes around if there are no vector ops.
Speeds up the compilation time of SelectionDAG on a big scalar workload by ~8%.
llvm-svn: 175929
It was incorrectly checking a Function* being an IntrinsicInst* which
isn't possible. It should always have been checking the CallInst* instead.
Added test case for x86 which ensures we only get one constant load.
It was 2 before this change.
rdar://problem/13267920
llvm-svn: 175853
pass. One of the callers of isKilled() can cope with overapproximation of kills
and the other can't, so I added a flag to indicate this.
In theory this could pessimize code slightly, but in practice most physical
register uses are kills, and most important kills of physical registers are the
only uses of that register prior to register allocation, so we can recognize
them as kills even without kill flags.
This is relevant because LiveIntervals gets rid of all kill flags.
llvm-svn: 175821
to TargetFrameLowering, where it belongs. Incidentally, this allows us
to delete some duplicated (and slightly different!) code in TRI.
There are potentially other layering problems that can be cleaned up
as a result, or in a similar manner.
The refactoring was OK'd by Anton Korobeynikov on llvmdev.
Note: this touches the target interfaces, so out-of-tree targets may
be affected.
llvm-svn: 175788
This fixes some problems with too conservative checking where we were
marking all aliases of a register as used, and then also checking all
aliases when allocating a register.
<rdar://problem/13249625>
llvm-svn: 175782
A legal BUILD_VECTOR goes in and gets constant folded into another legal
BUILD_VECTOR so we don't lose any legality here. The problematic PPC
optimization that made this check necessary was fixed recently.
llvm-svn: 175759
available.
With this commit there are no longer any assertion or verifier failures when
running 'make check' without LiveVariables. There are still 56 failing tests
with codegen differences and 1 unexpectedly passing test.
llvm-svn: 175719
Shuxin Yang