Daniel Jasper [Sun, 4 Jan 2015 09:11:17 +0000 (09:11 +0000)]
clang-format: Re-enable comment re-indentation for Java/JS.
This was broken by r224120.
llvm-svn: 225130
Nico Weber [Sun, 4 Jan 2015 08:07:54 +0000 (08:07 +0000)]
Fix indentation. No behavior change.
llvm-svn: 225129
Nico Weber [Sun, 4 Jan 2015 07:59:35 +0000 (07:59 +0000)]
Wrap to 80 columns, no behavior change.
llvm-svn: 225128
David Majnemer [Sun, 4 Jan 2015 07:36:02 +0000 (07:36 +0000)]
InstCombine: match can find ConstantExprs, don't assume we have a Value
We assumed the output of a match was a Value, this would cause us to
assert because we would fail a cast<>. Instead, use a helper in the
Operator family to hide the distinction between Value and Constant.
This fixes PR22087.
llvm-svn: 225127
David Majnemer [Sun, 4 Jan 2015 07:06:53 +0000 (07:06 +0000)]
ValueTracking: ComputeNumSignBits should tolerate misshapen phi nodes
PHI nodes can have zero operands in the middle of a transform. It is
expected that utilities in Analysis don't freak out when this happens.
Note that it is considered invalid to allow these misshapen phi nodes to
make it to another pass.
This fixes PR22086.
llvm-svn: 225126
Nico Weber [Sun, 4 Jan 2015 05:29:21 +0000 (05:29 +0000)]
Document that GetTypeForDeclarator() cannot return a null type.
Also add a few asserts for this. The existing code assumes this in a bunch
of places already (see e.g. the assert at the top of ParseTypedefDecl(), and
there are many unchecked calls on the result of GetTypeForDeclarator()), and
from looking through the code this should always be true from what I can tell.
This allows removing ASTContext::getNullTypeSourceInfo() too as that's now
unused.
No behavior change intended.
llvm-svn: 225125
Nico Weber [Sun, 4 Jan 2015 04:53:10 +0000 (04:53 +0000)]
Crash less enthusiasticially on _Atomic or __restrict__ on invalid types.
Many places in Sema cannot handle isNull() types. This is fine, because in
most places the type building code recovers by falling back to IntTy. In
GetFullTypeForDeclarator(), this is done at the end of the getNumTypeObjects()
loop body. This function calls BuildQualifiedType() before this fallback is
done though, so it explicitly needs to check for isNull() types.
llvm-svn: 225124
Lang Hames [Sun, 4 Jan 2015 01:20:55 +0000 (01:20 +0000)]
[APFloat][ADT] Fix sign handling logic for FMA results that truncate to zero.
This patch adds a check for underflow when truncating results back to lower
precision at the end of an FMA. The additional sign handling logic in
APFloat::fusedMultiplyAdd should only be performed when the result of the
addition step of the FMA (in full precision) is exactly zero, not when the
result underflows to zero.
Unit tests for this case and related signed zero FMA results are included.
Fixes <rdar://problem/
18925551>.
llvm-svn: 225123
Nico Weber [Sun, 4 Jan 2015 00:47:22 +0000 (00:47 +0000)]
Wrap to 80 columns, no behavior change.
llvm-svn: 225122
David Majnemer [Sun, 4 Jan 2015 00:44:32 +0000 (00:44 +0000)]
AST: Remove overzealous assertion from IsModifiable
It's reasonable to ask if an l-value with class type is modifiable.
llvm-svn: 225121
Saleem Abdulrasool [Sat, 3 Jan 2015 21:35:09 +0000 (21:35 +0000)]
llvm-readobj: add support to dump COFF export tables
This enhances llvm-readobj to print out the COFF export table, similar to the
-coff-import option. This is useful for testing in lld.
llvm-svn: 225120
Saleem Abdulrasool [Sat, 3 Jan 2015 21:35:00 +0000 (21:35 +0000)]
ARM: permit tail calls to weak externals on COFF
Weak externals are resolved statically, so we can actually generate the tail
call on PE/COFF targets without breaking the requirements. It is questionable
whether we want to propagate the current behaviour for MachO as the requirements
are part of the ARM ELF specifications, and it seems that prior to the SVN
r215890, we would have tail'ed the call. For now, be conservative and only
permit it on PE/COFF where the call will always be fully resolved.
llvm-svn: 225119
David Majnemer [Sat, 3 Jan 2015 19:41:00 +0000 (19:41 +0000)]
Parse: __attribute__((keyword)) shouldn't error
Weird constructs like __attribute__((inline)) or
__attibute__((typename)) should result in warnings, not errors.
llvm-svn: 225118
Hal Finkel [Sat, 3 Jan 2015 17:58:24 +0000 (17:58 +0000)]
[PowerPC/BlockPlacement] Allow target to provide a per-loop alignment preference
The existing code provided for specifying a global loop alignment preference.
However, the preferred loop alignment might depend on the loop itself. For
recent POWER cores, loops between 5 and 8 instructions should have 32-byte
alignment (while the others are better with 16-byte alignment) so that the
entire loop will fit in one i-cache line.
To support this, getPrefLoopAlignment has been made virtual, and can be
provided with an optional MachineLoop* so the target can inspect the loop
before answering the query. The default behavior, as before, is to return the
value set with setPrefLoopAlignment. MachineBlockPlacement now queries the
target for each loop instead of only once per function. There should be no
functional change for other targets.
llvm-svn: 225117
Aaron Ballman [Sat, 3 Jan 2015 17:00:12 +0000 (17:00 +0000)]
Volatile reads are side-effecting operations, but in the general case of access through a volatile-qualified type, we're not certain of the underlying object's side-effects on access.
Treat volatile accesses as "maybe" instead of "definite" side effects for the purposes of warning on evaluations in an unevaluated context. No longer diagnose on idiomatic code like:
int * volatile v;
(void)sizeof(*v);
llvm-svn: 225116
Hal Finkel [Sat, 3 Jan 2015 14:58:25 +0000 (14:58 +0000)]
[PowerPC] Use 16-byte alignment for modern cores for functions/loops
Most modern PowerPC cores prefer that functions and loops start on
16-byte-aligned boundaries (*), so instruct block placement, etc. to make this
happen. The branch selector has also been adjusted so account for the extra
nops that might now be inserted before loop headers.
(*) Some cores actually prefer other alignments for small loops, but that will
be addressed in a follow-up commit.
llvm-svn: 225115
Craig Topper [Sat, 3 Jan 2015 08:16:34 +0000 (08:16 +0000)]
Minor cleanup to all the switches after MatchInstructionImpl in all the AsmParsers.
Make sure they all have llvm_unreachable on the default path out of the switch. Remove unnecessary "default: break". Remove a 'return' after unreachable. Fix some indentation.
llvm-svn: 225114
Craig Topper [Sat, 3 Jan 2015 08:16:29 +0000 (08:16 +0000)]
Fix some formatting in tablegen output.
llvm-svn: 225113
Craig Topper [Sat, 3 Jan 2015 08:16:14 +0000 (08:16 +0000)]
Replace some 'unreachable' comments with llvm_unreachable.
llvm-svn: 225112
Alexey Samsonov [Sat, 3 Jan 2015 04:29:12 +0000 (04:29 +0000)]
Remove TSAN_DEBUG in favor of SANITIZER_DEBUG.
llvm-svn: 225111
Alexey Samsonov [Sat, 3 Jan 2015 04:29:05 +0000 (04:29 +0000)]
Replace DCHECK with DCHECK_LE where appropriate.
llvm-svn: 225110
David Majnemer [Sat, 3 Jan 2015 02:33:25 +0000 (02:33 +0000)]
ValueTracking: Make computeKnownBits for Arguments a little more clear
We would sometimes leave the out-param APInts untouched while going
through computeKnownBits. While I don't know of a way to trigger a bug
involving this in practice, it goes against the overall design of
computeKnownBits.
Found via code inspection.
llvm-svn: 225109
Kostya Serebryany [Sat, 3 Jan 2015 02:07:58 +0000 (02:07 +0000)]
[asan/tracing] extend the test a bit more, simplify the tracing code, add a guard page to trace array, fix the trace IDs before dumping
llvm-svn: 225108
Kostya Serebryany [Sat, 3 Jan 2015 01:41:11 +0000 (01:41 +0000)]
[asan] extend coverage-tracing.cc test
llvm-svn: 225107
Hal Finkel [Sat, 3 Jan 2015 01:16:37 +0000 (01:16 +0000)]
[PowerPC] Add support for the CMPB instruction
Newer POWER cores, and the A2, support the cmpb instruction. This instruction
compares its operands, treating each of the 8 bytes in the GPRs separately,
returning a 'mask' result of 0 (for false) or -1 (for true) in each byte.
Code generation support is added, in the form of a PPCISelDAGToDAG
DAG-preprocessing routine, that recognizes patterns close to what the
instruction computes (either exactly, or related by a constant masking
operation), and generates the cmpb instruction (along with any necessary
constant masking operation). This can be expanded if use cases arise.
llvm-svn: 225106
Saleem Abdulrasool [Sat, 3 Jan 2015 00:57:14 +0000 (00:57 +0000)]
test: correct PE/COFF tests to build under MSVC mode
This adjusts the inputs to be compatible with armv7-windows-msvc as well as
armv7-windows-itanium. NFC.
llvm-svn: 225105
Saleem Abdulrasool [Sat, 3 Jan 2015 00:57:10 +0000 (00:57 +0000)]
ReaderWriter: adjust ARM target addresses for exec
ARM NT assumes a THUMB only environment. As such, any address that is detected
as residing in an executable section is adjusted to have its bottom bit set to
indicate THUMB in case of a mode exchange.
Although the testing here seems insufficient (missing the negative cases) the
existing test cases for the IMAGE_REL_ARM_{ADDR32,MOV32T} are relevant as they
ensure that we do not incorrectly set the bit.
llvm-svn: 225104
Kostya Serebryany [Sat, 3 Jan 2015 00:54:43 +0000 (00:54 +0000)]
[asan] simplify the tracing code, make it use the same guard variables as coverage
llvm-svn: 225103
Rafael Espindola [Sat, 3 Jan 2015 00:28:47 +0000 (00:28 +0000)]
Remove -Werror from test.
It is not needed since we FileCheck for the warning and -Werror itself can end up
unused.
llvm-svn: 225102
Rafael Espindola [Sat, 3 Jan 2015 00:06:04 +0000 (00:06 +0000)]
Really don't warn about -flto/fno-lto :-(
This should fix the last bots.
llvm-svn: 225100
Craig Topper [Sat, 3 Jan 2015 00:00:20 +0000 (00:00 +0000)]
[X86] Disassembler support for move to/from %rax with a 32-bit memory offset is REX.W and AdSize prefix are both present.
llvm-svn: 225099
Craig Topper [Sat, 3 Jan 2015 00:00:14 +0000 (00:00 +0000)]
[X86] Use 32-bit sign extended immediate for 64-bit LOCK_ArithBinOp with sign extended immediate.
llvm-svn: 225098
Chandler Carruth [Fri, 2 Jan 2015 23:34:39 +0000 (23:34 +0000)]
[PM] Add proper documentation for the ModulePassManager and
FunctionPassManager. These never got documented, likely due to the
clutter of this header file. This fixes another problem people noticed
when they started trying to use the new pass manager.
I've also used this to document the aspirational constraints I would
like to hold passes to. I don't really have a better place to document
such things at this point, but eventually will probably create a proper
.rst file and page for the LLVM pass infrastructure that carries such
high-level concerns.
llvm-svn: 225097
Chandler Carruth [Fri, 2 Jan 2015 23:25:16 +0000 (23:25 +0000)]
[PM] Actually include the correct file name. Sorry for the breakage.
llvm-svn: 225096
Rafael Espindola [Fri, 2 Jan 2015 23:23:52 +0000 (23:23 +0000)]
Also avoid warning on -flto/-fno-lto on linux.
On OS X a .s file is preprocessed, it is not on linux, which is why the warning was still
showing up on linux but not OS X.
llvm-svn: 225095
Chandler Carruth [Fri, 2 Jan 2015 23:16:59 +0000 (23:16 +0000)]
[PM] Lift the majority of the template boilerplate used to implement the
concept-based polymorphism in the pass manager to a separate header.
I got feedback from someone reading the code and trying to use it that
this was really making it hard to dive in and start using these APIs and
that makes a lot of sense.
This only requires a moderate amount of gymnastics to separate in this
way, namely rinsing the PreservedAnalysis object through a template
argument in a few places so that it is dependent and we only examine it
on instantiation.
llvm-svn: 225094
Rafael Espindola [Fri, 2 Jan 2015 22:56:15 +0000 (22:56 +0000)]
Don't warn on unused -fno-lto.
It is somewhat common for CFLAGS to be used with .s files. We were
already ignoring -flto. This patch just does the same for -fno-lto.
llvm-svn: 225093
Chandler Carruth [Fri, 2 Jan 2015 22:51:44 +0000 (22:51 +0000)]
[PM] Fix some formatting where clang-format has improved recently.
llvm-svn: 225092
David Blaikie [Fri, 2 Jan 2015 22:07:26 +0000 (22:07 +0000)]
DebugInfo: Provide a less subtle way to set the debug location of simple ret instructions
un-XFAILing the test XFAIL'd in r225086 after it regressed in r225083.
llvm-svn: 225090
Saleem Abdulrasool [Fri, 2 Jan 2015 21:47:33 +0000 (21:47 +0000)]
Driver: honour the clang-cl behaviour on ARM as well
Unfortunately, MSVC does not indicate to the driver what target is being used.
This means that we cannot correctly select the target architecture for the
clang_rt component. This breaks down when targeting windows with the clang
driver as opposed to the clang-cl driver. This should fix the native ARM
buildbot tests.
llvm-svn: 225089
Alexey Samsonov [Fri, 2 Jan 2015 21:28:37 +0000 (21:28 +0000)]
Revert "Revert r224736: "[Sanitizer] Make CommonFlags immutable after initialization.""
Fix test failures by introducing CommonFlags::CopyFrom() to make sure
compiler doesn't insert memcpy() calls into runtime code.
Original commit message:
Protect CommonFlags singleton by adding const qualifier to
common_flags() accessor. The only ways to modify the flags are
SetCommonFlagsDefaults(), ParseCommonFlagsFromString() and
OverrideCommonFlags() functions, which are only supposed to be
called during initialization.
llvm-svn: 225088
Saleem Abdulrasool [Fri, 2 Jan 2015 20:00:55 +0000 (20:00 +0000)]
Driver: reuse getCompilerRT in place of addSanitizerRTWindows
The logic for addSanitizerRTWindows was performing the same logical operation as
getCompilerRT, which was previously fully generalised for Linux and Windows.
This avoids having a duplication of the logic for building up the name of a
clang_rt component. This change does move the current limitation for Windows
into getArchNameForCompilerRTLib, where it is assumed that the architecture for
Windows is always i386.
llvm-svn: 225087
David Blaikie [Fri, 2 Jan 2015 19:49:28 +0000 (19:49 +0000)]
Temporarily XFAIL fallout from r225083 while investigating.
Between this behavior and that fixed by r225083/r225000, I'll take the
latter over the former for now, but I'm immediately working on
understanding/addressing this behavior too.
(the fact that the code change in r225083 caused this change in behavior
is a bit troubling anyway - given that it looks & claims to be just a
preformance thing)
llvm-svn: 225086
David Blaikie [Fri, 2 Jan 2015 19:49:10 +0000 (19:49 +0000)]
DebugInfo: Remove some now-unnecessary location handling around function arguments.
r225000 generalized debug info line info handling for expressions such
that this code is no longer necessary.
This removes the last use of CGDebugInfo::getLocation, but not all the
uses of CGDebugInfo::CurLoc, which is still used internally in
CGDebugInfo. I'd like to do away with all of that & might succeed after
a few more patches.
llvm-svn: 225085
Philip Reames [Fri, 2 Jan 2015 19:46:49 +0000 (19:46 +0000)]
Reformat statepoint documentation and fix a couple of typos
Patch by Ramkumar Ramachandra <artagnon@gmail.com>.
llvm-svn: 225084
David Blaikie [Fri, 2 Jan 2015 19:06:25 +0000 (19:06 +0000)]
DebugInfo: Fix cases where location failed to be updated after r225000
The optimization (that appears to have been here since the earliest
implementation (r50848) & has become more complicated over the years) to
avoid recreating the debugloc if it would be the same was out of date
because ApplyDebugLocation was not re-updating the CurLoc/PrevLoc. This
optimization doesn't look terribly beneficial/necessary, so I'm removing
it - if it turns up in benchmarks, I'm happy to reconsider/reimplement
this with justification, but for now it just seems to add
complexity/problems.
llvm-svn: 225083
Saleem Abdulrasool [Fri, 2 Jan 2015 18:51:59 +0000 (18:51 +0000)]
ReaderWriter: teach the writer about IMAGE_REL_ARM_BRANCH24T
This adds support for IMAGE_REL_ARM_BRANCH24T relocations. Similar to the
IMAGE_REL_ARM_BLX32T relocation, this relocation requires munging an
instruction. The instruction encoding is quite similar, allowing us to reuse
the same munging implementation. This is needed by the entry point stubs for
modules provided by MSVCRT.
llvm-svn: 225082
Saleem Abdulrasool [Fri, 2 Jan 2015 18:51:36 +0000 (18:51 +0000)]
ReaderWriter: teach the writer about IMAGE_REL_ARM_BLX23T
This adds support for IMAGE_REL_ARM_BLX23T relocations. Similar to the
IMAGE_REL_ARM_MOV32T relocation, this relocation requires munging an
instruction. This inches us closer to supporting a basic hello world
application.
llvm-svn: 225081
Andrea Di Biagio [Fri, 2 Jan 2015 10:47:46 +0000 (10:47 +0000)]
Improved comments. No functional change intended.
llvm-svn: 225080
Chandler Carruth [Fri, 2 Jan 2015 09:59:38 +0000 (09:59 +0000)]
Revert r224736: "[Sanitizer] Make CommonFlags immutable after initialization."
We've got some internal users that either aren't compatible with this or
have found a bug with it. Either way, this is an isolated cleanup and so
I'm reverting it to un-block folks while we investigate. Alexey and
I will be working on fixing everything up so this can be re-committed
soon. Sorry for the noise and any inconvenience.
llvm-svn: 225079
Craig Topper [Fri, 2 Jan 2015 07:36:23 +0000 (07:36 +0000)]
[X86] Bring some better consistency to the naming of the move to/from %al/ax/eax/rax with memory offset.
llvm-svn: 225078
David Majnemer [Fri, 2 Jan 2015 07:29:47 +0000 (07:29 +0000)]
InstCombine: Detect when llvm.umul.with.overflow always overflows
We know overflow always occurs if both ~LHSKnownZero * ~RHSKnownZero
and LHSKnownOne * RHSKnownOne overflow.
llvm-svn: 225077
David Majnemer [Fri, 2 Jan 2015 07:29:43 +0000 (07:29 +0000)]
Analysis: Reformulate WillNotOverflowUnsignedMul for reusability
WillNotOverflowUnsignedMul's smarts will live in ValueTracking as
computeOverflowForUnsignedMul. It now returns a tri-state result:
never overflows, always overflows and sometimes overflows.
llvm-svn: 225076
Craig Topper [Fri, 2 Jan 2015 07:02:25 +0000 (07:02 +0000)]
[X86] Make the instructions that use AdSize16/32/64 co-exist together without using mode predicates.
This is necessary to allow the disassembler to be able to handle AdSize32 instructions in 64-bit mode when address size prefix is used.
Eventually we should probably also support 'addr32' and 'addr16' in the assembler to override the address size on some of these instructions. But for now we'll just use special operand types that will lookup the current mode size to select the right instruction.
llvm-svn: 225075
Chandler Carruth [Fri, 2 Jan 2015 03:55:54 +0000 (03:55 +0000)]
[SROA] Teach SROA to be more aggressive in splitting now that we have
a pre-splitting pass over loads and stores.
Historically, splitting could cause enough problems that I hamstrung the
entire process with a requirement that splittable integer loads and
stores must cover the entire alloca. All smaller loads and stores were
unsplittable to prevent chaos from ensuing. With the new pre-splitting
logic that does load/store pair splitting I introduced in r225061, we
can now very nicely handle arbitrarily splittable loads and stores. In
order to fully benefit from these smarts, we need to mark all of the
integer loads and stores as splittable.
However, we don't actually want to rewrite partitions with all integer
loads and stores marked as splittable. This will fail to extract scalar
integers from aggregates, which is kind of the point of SROA. =] In
order to resolve this, what we really want to do is only do
pre-splitting on the alloca slices with integer loads and stores fully
splittable. This allows us to uncover all non-integer uses of the alloca
that would benefit from a split in an integer load or store (and where
introducing the split is safe because it is just memory transfer from
a load to a store). Once done, we make all the non-whole-alloca integer
loads and stores unsplittable just as they have historically been,
repartition and rewrite.
The result is that when there are integer loads and stores anywhere
within an alloca (such as from a memcpy of a sub-object of a larger
object), we can split them up if there are non-integer components to the
aggregate hiding beneath. I've added the challenging test cases to
demonstrate how this is able to promote to scalars even a case where we
have even *partially* overlapping loads and stores.
This restores the single-store behavior for small arrays of i8s which is
really nice. I've restored both the little endian testing and big endian
testing for these exactly as they were prior to r225061. It also forced
me to be more aggressive in an alignment test to actually defeat SROA.
=] Without the added volatiles there, we actually split up the weird i16
loads and produce nice double allocas with better alignment.
This also uncovered a number of bugs where we failed to handle
splittable load and store slices which didn't have a begininng offset of
zero. Those fixes are included, and without them the existing test cases
explode in glorious fireworks. =]
I've kept support for leaving whole-alloca integer loads and stores as
splittable even for the purpose of rewriting, but I think that's likely
no longer needed. With the new pre-splitting, we might be able to remove
all the splitting support for loads and stores from the rewriter. Not
doing that in this patch to try to isolate any performance regressions
that causes in an easy to find and revert chunk.
llvm-svn: 225074
Chandler Carruth [Fri, 2 Jan 2015 02:47:38 +0000 (02:47 +0000)]
[SROA] Make the computation of adjusted pointers not leak GEP
instructions.
I noticed this when working on dialing up how aggressively we can
pre-split loads and stores. My test case wasn't passing because dead
GEPs into the allocas persisted when they were built by this routine.
This isn't terribly harmful, we still rewrote and promoted the alloca
and I can't conceive of how to cause this to happen in a case where we
will keep the exact same alloca but rewrite and promote the uses of it.
If that ever happened, we'd get an assert out of mem2reg.
So I don't have a direct test case yet, but the subsequent commit's test
case wouldn't pass without this. There are other problems fixed by this
patch that I spotted purely by inspection such as the fact that
getAdjustedPtr could have actually deleted dead base pointers. I don't
know how to get a base pointer to go into getAdjustedPtr today, so
I think this bug could never have manifested (and I certainly can't
write a test case for it) but, it wasn't the intent of the code. The
code really just wanted to GC the new instructions built. That can be
done more directly by comparing with the base pointer which is the only
non-new instruction that this code can return.
llvm-svn: 225073
Saleem Abdulrasool [Fri, 2 Jan 2015 02:32:05 +0000 (02:32 +0000)]
ReaderWriter: teach the writer about IMAGE_REL_ARM_MOV32T
This adds support for the IMAGE_REL_ARM_MOV32T relocation. This is one of the
most complicated relocations for the Window on ARM target. It involves
re-encoding an instruction to contain an immediate value which is the relocation
target.
llvm-svn: 225072
Nick Lewycky [Fri, 2 Jan 2015 01:33:12 +0000 (01:33 +0000)]
Instantiation of a CXXMethodDecl may fail when the parameter type cannot be instantiated. Do not crash in this case. Fixes PR22040!
The FIXME in the test is caused by TemplateDeclInstantiator::VisitCXXRecordDecl
returning a nullptr instead of creating an invalid decl. This is a common
pattern across all of TemplateDeclInstantiator, so I'm not comfortable changing
it. The reason it's not invalid in the class template is due to support for an
MSVC extension, see r137573.
llvm-svn: 225071
Chandler Carruth [Fri, 2 Jan 2015 00:34:29 +0000 (00:34 +0000)]
[SROA] Add a test case for r225068 / PR22080.
llvm-svn: 225070
Chandler Carruth [Fri, 2 Jan 2015 00:10:22 +0000 (00:10 +0000)]
[SROA] Fix the loop exit placement to be prior to indexing the splits
array. This prevents it from walking out of bounds on the splits array.
Bug found with the existing tests by ASan and by the MSVC debug build.
llvm-svn: 225069
Chandler Carruth [Thu, 1 Jan 2015 23:26:16 +0000 (23:26 +0000)]
[SROA] Fix two total think-os in r225061 that should have been caught on
a +asserts bootstrap, but my bootstrap had asserts off. Oops.
Anyways, in some places it is reasonable to cast (as a sanity check) the
pointer operand to a load or store to an instruction within SROA --
namely when the pointer operand is expected to be derived from an
alloca, and thus always an instruction. However, the pre-splitting code
also deals with loads and stores to non-alloca pointers and there we
need to just use the Value*. Nothing about the code relied on the
instruction cast, it was only there essentially as an invariant
assertion. Remove the two that don't actually hold.
This should fix the proximate issue in PR22080, but I'm also doing an
asserts bootstrap myself to see if there are other issues lurking.
I'll craft a reduced test case in a moment, but I wanted to get the tree
healthy as quickly as possible.
llvm-svn: 225068
Tobias Grosser [Thu, 1 Jan 2015 23:01:11 +0000 (23:01 +0000)]
Drop all constant scheduling dimensions
Schedule dimensions that have the same constant value accross all statements do
not carry any information, but due to the increased dimensionality of the
schedule cost compile time. To not pay this cost, we remove constant dimensions
if possible.
llvm-svn: 225067
Hal Finkel [Thu, 1 Jan 2015 19:33:59 +0000 (19:33 +0000)]
[PowerPC] use UINT64_C instead of ul
Attempting to fix PR22078 (building on 32-bit systems) by replacing my careless
use of 1ul to be a uint64_t constant with UINT64_C(1).
llvm-svn: 225066
Michael Gottesman [Thu, 1 Jan 2015 13:54:05 +0000 (13:54 +0000)]
Revert "Just use a using directive in SmallMapVector instead of inheriting from MapVector itself."
This reverts commit r225059. I think MSVC 2012 has a problem with this. This is
an attempt to fix one of the MSVC 2012 bots.
llvm-svn: 225065
Chandler Carruth [Thu, 1 Jan 2015 13:01:25 +0000 (13:01 +0000)]
Revert r225053: Add an ArrayRef upcasting constructor from ArrayRef<U*> -> ArrayRef<T*> where T is a base of U.
This appears to have broken at least the windows build bots due to
compile errors in the predicate that didn't simply supress the overload.
I'm not sure what the fix is, and the bots have been broken for a long
time now so I'm just reverting until Michael can figure out a fix.
llvm-svn: 225064
Chandler Carruth [Thu, 1 Jan 2015 12:56:47 +0000 (12:56 +0000)]
[SROA] Switch to using a more direct debug logging technique in one part
of my new load and store splitting, and fix a bug where it logged
a totally irrelevant slice rather than the actual slice in question.
The logging here previously worked because we used to place new slices
onto the back of the core sequence, but that caused other problems.
I updated the actual code to store new slices in their own vector but
didn't update the logging. There isn't a good way to reuse the logging
any more, and frankly it wasn't needed. We can directly log this bit
more easily.
llvm-svn: 225063
Chandler Carruth [Thu, 1 Jan 2015 12:01:03 +0000 (12:01 +0000)]
[SROA] Fix formatting with clang-format which I managed to fail to do
prior to committing r225061. Sorry for that.
llvm-svn: 225062
Chandler Carruth [Thu, 1 Jan 2015 11:54:38 +0000 (11:54 +0000)]
[SROA] Teach SROA how to much more intelligently handle split loads and
stores.
When there are accesses to an entire alloca with an integer
load or store as well as accesses to small pieces of the alloca, SROA
splits up the large integer accesses. In order to do that, it uses bit
math to merge the small accesses into large integers. While this is
effective, it produces insane IR that can cause significant problems in
the rest of the optimizer:
- It can cause load and store mismatches with GVN on the non-alloca side
where we end up loading an i64 (or some such) rather than loading
specific elements that are stored.
- We can't always get rid of the integer bit math, which is why we can't
always fix the loads and stores to work well with GVN.
- This is especially bad when we have operations that mix poorly with
integer bit math such as floating point operations.
- It will block things like the vectorizer which might be able to handle
the scalar stores that underly the aggregate.
At the same time, we can't just directly split up these loads and stores
in all cases. If there is actual integer arithmetic involved on the
values, then using integer bit math is actually the perfect lowering
because we can often combine it heavily with the surrounding math.
The solution this patch provides is to find places where SROA is
partitioning aggregates into small elements, and look for splittable
loads and stores that it can split all the way to some other adjacent
load and store. These are uniformly the cases where failing to split the
loads and stores hurts the optimizer that I have seen, and I've looked
extensively at the code produced both from more and less aggressive
approaches to this problem.
However, it is quite tricky to actually do this in SROA. We may have
loads and stores to the same alloca, or other complex patterns that are
hard to handle. This complexity leads to the somewhat subtle algorithm
implemented here. We have to do this entire process as a separate pass
over the partitioning of the alloca, and split up all of the loads prior
to splitting the stores so that we can handle safely the cases of
overlapping, including partially overlapping, loads and stores to the
same alloca. We also have to reconstitute the post-split slice
configuration so we can avoid iterating again over all the alloca uses
(the slow part of SROA). But we also have to ensure that when we split
up loads and stores to *other* allocas, we *do* re-iterate over them in
SROA to adapt to the more refined partitioning now required.
With this, I actually think we can fix a long-standing TODO in SROA
where I avoided splitting as many loads and stores as probably should be
splittable. This limitation historically mitigated the fallout of all
the bad things mentioned above. Now that we have more intelligent
handling, I plan to remove the FIXME and more aggressively mark integer
loads and stores as splittable. I'll do that in a follow-up patch to
help with bisecting any fallout.
The net result of this change should be more fine-grained and accurate
scalars being formed out of aggregates. At the very least, Clang now
generates perfect code for this high-level test case using
std::complex<float>:
#include <complex>
void g1(std::complex<float> &x, float a, float b) {
x += std::complex<float>(a, b);
}
void g2(std::complex<float> &x, float a, float b) {
x -= std::complex<float>(a, b);
}
void foo(const std::complex<float> &x, float a, float b,
std::complex<float> &x1, std::complex<float> &x2) {
std::complex<float> l1 = x;
g1(l1, a, b);
std::complex<float> l2 = x;
g2(l2, a, b);
x1 = l1;
x2 = l2;
}
This code isn't just hypothetical either. It was reduced out of the hot
inner loops of essentially every part of the Eigen math library when
using std::complex<float>. Those loops would consistently and
pervasively hop between the floating point unit and the integer unit due
to bit math extraction and insertion of floating point values that were
"stored" in a 64-bit integer register around the loop backedge.
So far, this change has passed a bootstrap and I have done some other
testing and so far, no issues. That doesn't mean there won't be though,
so I'll be prepared to help with any fallout. If you performance swings
in particular, please let me know. I'm very curious what all the impact
of this change will be. Stay tuned for the follow-up to also split more
integer loads and stores.
llvm-svn: 225061
David Majnemer [Thu, 1 Jan 2015 09:49:44 +0000 (09:49 +0000)]
CodeGen: Don't crash when a lambda uses a local constexpr variable
The DeclRefExpr might be for a variable initialized by a constant
expression which hasn't been ODR used.
Emit the initializer for the variable instead of trying to capture the
variable itself.
This fixes PR22071.
llvm-svn: 225060
Michael Gottesman [Thu, 1 Jan 2015 08:05:41 +0000 (08:05 +0000)]
Just use a using directive in SmallMapVector instead of inheriting from MapVector itself.
llvm-svn: 225059
Saleem Abdulrasool [Thu, 1 Jan 2015 03:39:48 +0000 (03:39 +0000)]
test: fix tests/buildbots
Correct the yaml definition for the object. Adjust the symbol storage class
which was flipped for the two symbols, resulting in the link failure due to the
symbol missing. Adjust the virtual address of the section. This ripples into
the test case, since the data has been shifted up by 4 bytes.
llvm-svn: 225058
Saleem Abdulrasool [Thu, 1 Jan 2015 03:11:53 +0000 (03:11 +0000)]
ReaderWriter: teach the writer about IMAGE_REL_ARM_ADDR32
This implements the IMAGE_REL_ARM_ADDR32 relocation. There are still a few more
relocation types that need to resolved before lld can even attempt to link a
trivial program for Windows on ARM.
llvm-svn: 225057
Hal Finkel [Thu, 1 Jan 2015 02:53:29 +0000 (02:53 +0000)]
[PowerPC] Improve instruction selection bit-permuting operations (64-bit)
This is the second installment of improvements to instruction selection for "bit
permutation" instruction sequences. r224318 added logic for instruction
selection for 32-bit bit permutation sequences, and this adds lowering for
64-bit sequences. The 64-bit sequences are more complicated than the 32-bit
ones because:
a) the 64-bit versions of the 32-bit rotate-and-mask instructions
work by replicating the lower 32-bits of the value-to-be-rotated into the
upper 32 bits -- and integrating this into the cost modeling for the various
bit group operations is non-trivial
b) unlike the 32-bit instructions in 32-bit mode, the rotate-and-mask instructions
cannot, in one instruction, specify the
mask starting index, the mask ending index, and the rotation factor. Also,
forming arbitrary 64-bit constants is more complicated than in 32-bit mode
because the number of instructions necessary is value dependent.
Plus, support for 'late masking' was added: it is sometimes more efficient to
treat the overall value as if it had no mandatory zero bits when planning the
bit-group insertions, and then mask them in at the very end. Unfortunately, as
the structure of the bit groups is different in the two cases, the more
feasible implementation technique was to generate both instruction sequences,
and then pick the shorter one.
And finally, we now generate reasonable code for i64 bswap:
rldicl 5, 3, 16, 0
rldicl 4, 3, 8, 0
rldicl 6, 3, 24, 0
rldimi 4, 5, 8, 48
rldicl 5, 3, 32, 0
rldimi 4, 6, 16, 40
rldicl 6, 3, 48, 0
rldimi 4, 5, 24, 32
rldicl 5, 3, 56, 0
rldimi 4, 6, 40, 16
rldimi 4, 5, 48, 8
rldimi 4, 3, 56, 0
vs. what we used to produce:
li 4, 255
rldicl 5, 3, 24, 40
rldicl 6, 3, 40, 24
rldicl 7, 3, 56, 8
sldi 8, 3, 8
sldi 10, 3, 24
sldi 12, 3, 40
rldicl 0, 3, 8, 56
sldi 9, 4, 32
sldi 11, 4, 40
sldi 4, 4, 48
andi. 5, 5, 65280
andis. 6, 6, 255
andis. 7, 7, 65280
sldi 3, 3, 56
and 8, 8, 9
and 4, 12, 4
and 9, 10, 11
or 6, 7, 6
or 5, 5, 0
or 3, 3, 4
or 7, 9, 8
or 4, 6, 5
or 3, 3, 7
or 3, 3, 4
which is 12 instructions, instead of 25, and seems optimal (at least in terms
of code size).
llvm-svn: 225056
Michael Gottesman [Wed, 31 Dec 2014 23:33:24 +0000 (23:33 +0000)]
Add 2x constructors for TinyPtrVector, one that takes in one elemenet and the other that takes in an ArrayRef<EltTy>
Currently one can only construct an empty TinyPtrVector. These are just missing
elements of the API.
llvm-svn: 225055
Michael Gottesman [Wed, 31 Dec 2014 23:33:21 +0000 (23:33 +0000)]
Add a SmallMapVector class that is a MapVector with a Map of SmallDenseMap and a Vector of SmallVector.
llvm-svn: 225054
Michael Gottesman [Wed, 31 Dec 2014 23:33:18 +0000 (23:33 +0000)]
Add an ArrayRef upcasting constructor from ArrayRef<U*> -> ArrayRef<T*> where T is a base of U.
llvm-svn: 225053
Saleem Abdulrasool [Wed, 31 Dec 2014 22:32:21 +0000 (22:32 +0000)]
ReaderWriter: teach PE/COFF backend about ARM NT
This teaches lld about the ARM NT object types. Add a trivial test to ensure
that it can handle ARM NT object file inputs. It is still unable to perform the
necessary relocations for ARM NT, but this allows the linker to at least read
the objects.
llvm-svn: 225052
David Blaikie [Wed, 31 Dec 2014 22:30:31 +0000 (22:30 +0000)]
XFAIL test on win32 due to missing __complex support
llvm-svn: 225051
Sanjay Patel [Wed, 31 Dec 2014 22:14:05 +0000 (22:14 +0000)]
InstCombine: fsub nsz 0, X ==> fsub nsz -0.0, X
Some day the backend may handle instruction-level fast math flags and make
this transform unnecessary, but it's still better practice to use the canonical
representation of fneg when possible (use a -0.0).
This is a partial fix for PR20870 ( http://llvm.org/bugs/show_bug.cgi?id=20870 ).
See also http://reviews.llvm.org/D6723.
Differential Revision: http://reviews.llvm.org/D6731
llvm-svn: 225050
Rafael Espindola [Wed, 31 Dec 2014 18:20:52 +0000 (18:20 +0000)]
Avoid building compiler-rt with LTO.
During a LTO we still need to build a compiler_rt with regular object files
in the .a.
llvm-svn: 225049
Rafael Espindola [Wed, 31 Dec 2014 17:19:34 +0000 (17:19 +0000)]
Add r224985 back with a fix.
The issues was that AArch64 has additional restrictions on when local
relocations can be used. We have to take those into consideration when
deciding to put a L symbol in the symbol table or not.
Original message:
Remove doesSectionRequireSymbols.
In an assembly expression like
bar:
.long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero
addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 225048
Colin LeMahieu [Wed, 31 Dec 2014 17:14:35 +0000 (17:14 +0000)]
Reverting 225045 and 225043 and XFAIL multiline.ll on hexagon
llvm-svn: 225047
Rafael Espindola [Wed, 31 Dec 2014 16:58:05 +0000 (16:58 +0000)]
Add a test for the recent compiler-rt build failure.
llvm-svn: 225046
Colin LeMahieu [Wed, 31 Dec 2014 16:20:00 +0000 (16:20 +0000)]
[Hexagon] Removing assertion to appease buildbot until I can reproduce the problem
llvm-svn: 225045
Rafael Espindola [Wed, 31 Dec 2014 16:06:48 +0000 (16:06 +0000)]
Revert "Remove doesSectionRequireSymbols."
This reverts commit r224985.
I am investigating why it made an Apple bot unhappy.
llvm-svn: 225044
Colin LeMahieu [Wed, 31 Dec 2014 15:57:38 +0000 (15:57 +0000)]
[Hexagon] Changing an llvm_unreachable to an assertion and returning 0. Relocations aren't implemented yet but we don't need to abort for this in release builds.
llvm-svn: 225043
Tom Stellard [Wed, 31 Dec 2014 15:27:59 +0000 (15:27 +0000)]
r600: get_work_dim: Update metadata syntax for LLVM 3.6
llvm-svn: 225042
Tom Stellard [Wed, 31 Dec 2014 15:27:53 +0000 (15:27 +0000)]
Require LLVM 3.6 and bump version to 0.1.0
Some functions are implemented using hand-written LLVM IR, and
LLVM assembly format is allowed to change between versions, so we
should require a specific version of LLVM.
llvm-svn: 225041
Ted Kremenek [Wed, 31 Dec 2014 08:19:08 +0000 (08:19 +0000)]
[analyzer] Include a couple more comments on using xcrun to query the SDK.
llvm-svn: 225039
Ted Kremenek [Wed, 31 Dec 2014 07:44:51 +0000 (07:44 +0000)]
[analyzer] Change ccc-analyzer to mimick behavior on OSX Mavericks/Yosemite to automatically infer the SDK location.
llvm-svn: 225038
Craig Topper [Wed, 31 Dec 2014 07:24:23 +0000 (07:24 +0000)]
[X86] Update disassembler tests for absolute move instructions to check the encodings. This provides testing for r225036. 64-bit mode is still broken.
llvm-svn: 225037
Craig Topper [Wed, 31 Dec 2014 07:07:31 +0000 (07:07 +0000)]
[X86] Fix disassembly of absolute moves to work correctly in 16 and 32-bit modes with all 4 combinations of OpSize and AdSize prefixes being present or not.
llvm-svn: 225036
Craig Topper [Wed, 31 Dec 2014 07:07:11 +0000 (07:07 +0000)]
[x86] Simplify detection of jcxz/jecxz/jrcxz in disassembler.
llvm-svn: 225035
David Majnemer [Wed, 31 Dec 2014 04:21:41 +0000 (04:21 +0000)]
InstCombine: try to transform A-B < 0 into A < B
We are allowed to move the 'B' to the right hand side if we an prove
there is no signed overflow and if the comparison itself is signed.
llvm-svn: 225034
Andrew Wilkins [Wed, 31 Dec 2014 03:46:49 +0000 (03:46 +0000)]
[llgo] Elide alloca for unused received values in select
Summary: If a receive case in a select statement is not assigned to a named variable, then we can eliminate the alloca and copy at runtime.
Test Plan: lit test added
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6785
llvm-svn: 225033
Alexey Samsonov [Wed, 31 Dec 2014 00:40:28 +0000 (00:40 +0000)]
Revert "merge consecutive stores of extracted vector elements"
This reverts commit r224611. This change causes crashes
in X86 DAG->DAG Instruction Selection.
llvm-svn: 225031
Peter Collingbourne [Wed, 31 Dec 2014 00:25:39 +0000 (00:25 +0000)]
irgen: modify the ABI to use init guards instead of priority
The new ABI is simpler for use cases such as dynamically loaded packages.
The calling convention for import functions is similar to what go/ssa would
produce if BareInits were cleared. However, simply clearing this flag causes
two additional issues:
1) We would need to special case the 'init$guard' variable (see
discussion in https://codereview.appspot.com/
78780043/).
2) The call to __go_register_gc_roots needs to appear in the right
place, i.e. after the guard check. Making this check appear
in the right place with non-bare inits seems unreliable at best.
So we keep BareInits set and generate the necessary code manually.
It is still possible to get the old ABI by specifying a path to a gccgo
installation.
Differential Revision: http://reviews.llvm.org/D6804
llvm-svn: 225030
Peter Collingbourne [Wed, 31 Dec 2014 00:25:36 +0000 (00:25 +0000)]
irgen: make it possible to use a custom importer
Differential Revision: http://reviews.llvm.org/D6803
llvm-svn: 225029
Peter Collingbourne [Wed, 31 Dec 2014 00:25:35 +0000 (00:25 +0000)]
irgen: return a types.Package to the compiler client
Differential Revision: http://reviews.llvm.org/D6802
llvm-svn: 225028
Peter Collingbourne [Wed, 31 Dec 2014 00:25:34 +0000 (00:25 +0000)]
irgen: introduce ManglePackagePath function
This is useful for clients that need to use llgo's mangling of the package
path to look up a specific function within a given package.
Differential Revision: http://reviews.llvm.org/D6801
llvm-svn: 225027