This is a skeleton for a pre-RA MachineInstr scheduler strategy. Currently
it only tries to expose more parallelism for ALU instructions (this also
makes the distribution of GPR channels more uniform and increases the
chances of ALU instructions to be packed together in a single VLIW group).
Also it tries to reduce clause switching by grouping instruction of the
same kind (ALU/FETCH/CF) together.
Vincent Lejeune:
- Support for VLIW4 Slot assignement
- Recomputation of ScheduleDAG to get more parallelism opportunities
Tom Stellard:
- Fix assertion failure when trying to determine an instruction's slot
based on its destination register's class
- Fix some compiler warnings
Vincent Lejeune: [v2]
- Remove recomputation of ScheduleDAG (will be provided in a later patch)
- Improve estimation of an ALU clause size so that heuristic does not emit cf
instructions at the wrong position.
- Make schedule heuristic smarter using SUnit Depth
- Take constant read limitations into account
Vincent Lejeune: [v3]
- Fix some uninitialized values in ConstPair
- Add asserts to ensure an ALU slot is always populated
llvm-svn: 176498
Clarify that we mean the object starting at the pointer to the end of the
underlying object and not the size of the whole allocated object.
llvm-svn: 176491
Maintaining CONST_COPY Instructions until Pre Emit may prevent some ifcvt case
and taking them in account for scheduling is difficult for no real benefit.
llvm-svn: 176488
Reviewed-by: Tom Stellard <thomas.stellard at amd.com>
mayLoad complexify scheduling and does not bring any usefull info
as the location is not writeable at all.
llvm-svn: 176486
one-byte NOPs. If the processor actually executes those NOPs, as it sometimes
does with aligned bundling, this can have a performance impact. From my
micro-benchmarks run on my one machine, a 15-byte NOP followed by twelve
one-byte NOPs is about 20% worse than a 15 followed by a 12. This patch
changes NOP emission to emit as many 15-byte (the maximum) as possible followed
by at most one shorter NOP.
llvm-svn: 176464
* Only apply divide bypass optimization when not optimizing for size.
* Fixed bug caused by constant for 0 value of type Int32,
used dividend type to generate the constant instead.
* For atom x86-64 apply the divide bypass to use 16-bit divides instead of
64-bit divides when operand values are small enough.
* Added lit tests for 64-bit divide bypass.
Patch by Tyler Nowicki!
llvm-svn: 176442
The VDUP instruction source register doesn't allow a non-constant lane
index, so make sure we don't construct a ARM::VDUPLANE node asking it to
do so.
rdar://13328063
http://llvm.org/bugs/show_bug.cgi?id=13963
llvm-svn: 176413
This adds minimalistic support for PHI nodes to llvm.objectsize() evaluation
fingers crossed so that it does break clang boostrap again..
llvm-svn: 176408
This matters for example in following matrix multiply:
int **mmult(int rows, int cols, int **m1, int **m2, int **m3) {
int i, j, k, val;
for (i=0; i<rows; i++) {
for (j=0; j<cols; j++) {
val = 0;
for (k=0; k<cols; k++) {
val += m1[i][k] * m2[k][j];
}
m3[i][j] = val;
}
}
return(m3);
}
Taken from the test-suite benchmark Shootout.
We estimate the cost of the multiply to be 2 while we generate 9 instructions
for it and end up being quite a bit slower than the scalar version (48% on my
machine).
Also, properly differentiate between avx1 and avx2. On avx-1 we still split the
vector into 2 128bits and handle the subvector muls like above with 9
instructions.
Only on avx-2 will we have a cost of 9 for v4i64.
I changed the test case in test/Transforms/LoopVectorize/X86/avx1.ll to use an
add instead of a mul because with a mul we now no longer vectorize. I did
verify that the mul would be indeed more expensive when vectorized with 3
kernels:
for (i ...)
r += a[i] * 3;
for (i ...)
m1[i] = m1[i] * 3; // This matches the test case in avx1.ll
and a matrix multiply.
In each case the vectorized version was considerably slower.
radar://13304919
llvm-svn: 176403
The LoopVectorizer often runs multiple times on the same function due to inlining.
When this happens the loop vectorizer often vectorizes the same loops multiple times, increasing code size and adding unneeded branches.
With this patch, the vectorizer during vectorization puts metadata on scalar loops and marks them as 'already vectorized' so that it knows to ignore them when it sees them a second time.
PR14448.
llvm-svn: 176399
Fix the way resources are counted. I'm taking some time to cleanup the
way MachineScheduler handles in-order machine resources. Eventually
we'll need more PPC/Atom test cases in tree.
llvm-svn: 176390
The sys::fs::is_directory() check is unnecessary because, if the filename is
a directory, the function will fail anyway with the same error code returned.
Remove the check to avoid an unnecessary stat call.
Someone needs to review on windows and see if the check is necessary there or not.
llvm-svn: 176386
This patch eliminates the need to emit a constant move instruction when this
pattern is matched:
(select (setgt a, Constant), T, F)
The pattern above effectively turns into this:
(conditional-move (setlt a, Constant + 1), F, T)
llvm-svn: 176384
detail.
The was this test was written, it was relying on an implementation detail
(fixups) and hence was very brittle (relying, among other things, on the
exact ordering of statistics printed by MC).
The test was rewritten to check a more observable output difference. While it
doesn't cover 100% of the things the original test covered, it's a good
practice to write regression tests this way. If we want to check that
internal details and invariants hold, such tests should be expressed as unit
tests.
llvm-svn: 176377
The make (all) target takes care of creating lit configs and auto-generating
tests. The problem with the original 'lit.site.cfg' target is it's not
recursive and doesn't fully create everything necessary for testing
clang-tools-extra.
llvm-svn: 176374
This reduces the time actually spent doing string to ID conversion and shows a 10% improvement in compile time for a particularly bad case that involves ARM Neon intrinsics (these have many overloads).
Patch by Jean-Luc Duprat!
llvm-svn: 176365
- 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
dispatch code. As far as I can tell the thumb2 code is behaving as expected.
I was able to compile and run the associated test case for both arm and thumb1.
rdar://13066352
llvm-svn: 176363
v2: based on Michels patch, but now allows copying of all registers sizes.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 176346
This function will be used later when the capability to search delay slot
filling instructions in successor blocks is added. No intended functionality
changes.
llvm-svn: 176325
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
- if you have LLDB checked out in $llvm/tools, CMake will build it now!
- LLDB is known to build on Linux with libstdc++ and GCC 4.6/4.7 or Clang 3.3
- to run lldb tests, do "make check-lldb" after a build
llvm-svn: 176307
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
This was causing the folding set to fail to fold attributes, because it was
being calculated in one spot without an empty values string but here with an
empty values string.
llvm-svn: 176301
The instcombine recognized pattern looks like:
a = b * c
d = a +/- Cst
or
a = b * c
d = Cst +/- a
When creating the new operands for fadd or fsub instruction following the related fmul, the first operand was created with the second original operand (M0 was created with C1) and the second with the first (M1 with Opnd0).
The fix consists in creating the new operands with the appropriate original operand, i.e., M0 with Opnd0 and M1 with C1.
llvm-svn: 176300
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
The work done by the post-encoder (setting architecturally unused bits to 0 as
required) can be done by the existing operand that covers the "#0.0". This
removes at least one use of the discouraged PostEncoderMethod uses.
llvm-svn: 176261
If an otherwise weak var is actually defined in this unit, it can't be
undefined at runtime so we can use normal global variable sequences (ADRP/ADD)
to access it.
llvm-svn: 176259
- Consistency with opt (which supports the same option with the same meaning and
description).
- Debugging gold plugin-based linking without optimizations getting in the way.
- Debugging programs linked with the gold plugin while preserving the original
debug info.
- Fine-grained control over LTO passes using the gold plugin in combination with
opt (or clang/dragonegg).
Patch by Cristiano Giuffrida!
llvm-svn: 176257
Shadow checks are disabled and memory loads always produce fully initialized
values in functions that don't have a sanitize_memory attribute. Value and
argument shadow is propagated as usual.
This change also updates blacklist behaviour to match the above.
llvm-svn: 176247
Most of the tests that behave differently on llvm-arm-linux buildbot
did so becase the triple wasn't set correctly to armv5, so we can
revert most of the special behaviour added previously. Some tests
still need the special treatment, though.
llvm-svn: 176243
to create the parent path.
This can happen if the path is a relative filename and the current directory was removed.
Thanks to Daniel D. for the hint in fixing it.
llvm-svn: 176226
This problem is exposed by r171325 which is already reverted. It is rather
hard to fabricate a testing case without it.
r171325 should *NOT* be resurrected as it has a potential problem although
this problem dosen't directly contribute to PR14988.
The bug is tracked by:
- rdar://13063553, and
- http://llvm.org/bugs/show_bug.cgi?id=14988
Thank Arnold for coming up a better solution to this problem. After
comparing this solution and my original proposal, I decided to ditch mine.
llvm-svn: 176225
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
Test case is missing due to it not being reachable through the current tools
but out of tree code such as the sample at
http://llvm.org/docs/tutorial/LangImpl4.html
Patch by Peng Cheng <gm4cheng@gmail.com>
llvm-svn: 176213
This fixes an issue where trying to assemlbe valid ADR instructions would cause
LLVM to hit a failed assertion.
Patch by Keith Walker.
llvm-svn: 176189
This properly asks TargetLibraryInfo if a call is available and if it is, it
can be translated into the corresponding LLVM builtin. We don't vectorize sqrt()
yet because I'm not sure about the semantics for negative numbers. The other
intrinsic should be exact equivalents to the libm functions.
Differential Revision: http://llvm-reviews.chandlerc.com/D465
llvm-svn: 176188
PR15262 reported a bug where the following instruction:
i8 getelementptr inbounds i8* bitcast ([4 x i8] addrspace(12)* @buf to i8*),
i32 2
was getting folded into:
addrspace(12)* getelementptr inbounds ([4 x i8] addrspace(12)* @buf, i32 0,
i32 2)
This caused instcombine to crash because the original instruction and
the folded instruction have different types. The issue was fixed by
disallowing bitcasts between different address spaces to be folded away.
llvm-svn: 176156
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
enhancement done the trivial way; by extending inputs and truncating outputs
which is addequate for targets with little or no support for integer arithmetic
on integer types less than 32 bits.
llvm-svn: 176139
There's no need to generate a stack frame for PPC32 SVR4 when there are
no local variables assigned to the stack, i.e., when no red zone is needed.
(PPC64 supports a red zone, but PPC32 does not.)
llvm-svn: 176124
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
For integer constants, allow 'L', 'UL' as well as 'ULL' and 'LL'. This provides
better support for shared headers between .s and .c files that define bunches
of constant values.
rdar://9321056
llvm-svn: 176118
Make it possible to map between e32 and e64 encoding opcodes.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 176104
Include immediate folding and SGPR limit handling for VOP3 instructions.
v2: remove leftover hasExtraSrcRegAllocReq
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 176101
v2: document why we hardcode VCC for now.
This is a candidate for the mesa-stable branch.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 176099
Prevent producing real strange tablegen code by using
proper register sizes, alignments and hierarchy.
Also cleanup the unused definitions and add some comments.
v2: add SGPR 512 bit registers, stop registers from wrapping around,
fix SGPR alignment
This is a candidate for the mesa-stable branch.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 176098
This is a candidate for the mesa-stable branch.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 176097
The PowerPC TLS relocation types were not previously added to the
necessary list in MCELFStreamer::fixSymbolsInTLSFixups(). Now they are!
llvm-svn: 176094
These are two related changes (one in llvm, one in clang).
LLVM:
- rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode)
- rename thread_safety => sanitize_thread
- rename no_uninitialized_checks -> sanitize_memory
CLANG:
- add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis))
- add __attribute__((no_sanitize_thread))
- add __attribute__((no_sanitize_memory))
for S in address thread memory
If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not
set llvm attribute sanitize_S
llvm-svn: 176075
This changes the RecordingMemoryManager in lli to use mapped memory rather than malloc to allocate memory for sections and uses a 'near' MemoryBlock to keep the allocations together. This works around a problem in MCJIT where relocations are applied to a generated image immediately oupon generation, which isn't appropriate for the remote case.
llvm-svn: 176057
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
This removes a const_cast hack from PPCRegisterInfo::hasReservedSpillSlot().
The proper place to save the frame index for the CR spill slot is in the
PPCFunctionInfo object, not the PPCRegisterInfo object.
No new test cases, as this just reimplements existing function. Existing
tests such as test/CodeGen/PowerPC/crsave.ll are sufficient.
llvm-svn: 175998
This is a common pattern with dyn_cast and similar constructs, when the
PHI no longer depends on the select it can often be turned into a simpler
construct or even get hoisted out of the loop.
PR15340.
llvm-svn: 175995
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
Jyotsna Verma