David Blaikie [Thu, 29 Jan 2015 19:09:18 +0000 (19:09 +0000)]
DebugInfo: Teach Fast ISel to respect the debug location of comparisons in jumps
The use of the DbgLoc in FastISel is probably something we should fix.
It's prone to leaking the wrong location into instructions - we should
have a clear chain of custody from the debug location of an IR
Instruction to that of a MachineInstr to avoid such leakage.
Zachary Turner [Thu, 29 Jan 2015 18:44:14 +0000 (18:44 +0000)]
Disable compilation of llvm-pdbdump for versions of MSVC < 2013.
Certain aspects of llvm-pdbdump require language support only present in
MSVC 2013 and higher. Since this is strictly a utility, and since we hope
to drop support for MSVC 2012 soon, don't build this unless MSVC 2013 or
higher.
Robert Lougher [Thu, 29 Jan 2015 16:18:29 +0000 (16:18 +0000)]
[X86] Use single add/sub for large stack offsets
For large stack offsets the compiler generates multiple immediate mode
sub/add instructions in the prologue/epilogue. This patch makes the
compiler place the final amount to be added/subtracted into a register,
which is then added/substracted with a single operation.
Bill Schmidt [Thu, 29 Jan 2015 15:59:09 +0000 (15:59 +0000)]
[PowerPC] Complete setting the baseline for ppc64le
Patch by Nemanja Ivanovic.
As was uncovered by the failing test case (when run on non-PPC
platforms), the feature set when compiling with -march=ppc64le was not
being picked up. This change ensures that if the -mcpu option is not
specified, the correct feature set is picked up regardless of whether
we are on PPC or not.
Aaron Ballman [Thu, 29 Jan 2015 15:49:22 +0000 (15:49 +0000)]
Temporarily reverting the fuzzer library as it causes too many build issues for MSVC users. This reverts: 227445, 227395, 227389, 227357, 227254, 227252
James Molloy [Thu, 29 Jan 2015 13:48:05 +0000 (13:48 +0000)]
[LoopReroll] Refactor most of reroll() into a helper class
reroll() was slightly monolithic and a pain to modify. Refactor
a bunch of its state from local variables to member variables
of a helper class, and do some trivial simplification while we're
there.
Vladimir Medic [Thu, 29 Jan 2015 11:33:41 +0000 (11:33 +0000)]
[Mips][Disassembler] When disassembler meets cache/pref instructions for r6 it crashes as the access to operands array is out of range. This patch adds dedicated decoder method for R6 CACHE_HINT_DESC class that properly handles decoding of these instructions.
Owen Anderson [Thu, 29 Jan 2015 07:35:31 +0000 (07:35 +0000)]
Use the existing build configuration parameter ENABLE_BACKTRACE to compile out all pretty stack trace support when backtraces are disabled.
This has the nice secondary effect of allowing LLVM to continue to build
for targets without __thread or thread_local support to continue to work
so long as they build without support for backtraces.
Chandler Carruth [Thu, 29 Jan 2015 02:34:17 +0000 (02:34 +0000)]
[LPM] Try again to appease powerpc64 in its self host. I've been unable
to get a powerpc64 host so that I can reproduce and test this, but it
only impacts that platform so trying the only other realistic option.
According to Ulrich, who debugged this initially, initial-exec is likely
to be sufficient for our needs and not subject to this bug. Will watch
the build bots to see.
If this doesn't work, I'll be forced to cut a really ugly pthread-based
approach into the primary user (our stack trace printing) as that user
cannot use the ThreadLocal implementation due to lifetime issues.
Chandler Carruth [Thu, 29 Jan 2015 01:23:04 +0000 (01:23 +0000)]
[LPM] Clean up the use of TLS in pretty stack trace and disable it
entirely when threads are not enabled. This should allow anyone who
needs to bootstrap or cope with a host loader without TLS support to
limp along without threading support.
There is still some bug in the PPC TLS stuff that is not worked around.
I'm getting access to a machine to reproduce and debug this further.
There is some chance that I'll have to add a terrible workaround for
PPC.
There is also some problem with iOS, but I have no ability to really
evaluate what the issue is there. I'm leaving it to folks maintaining
that platform to suggest a path forward -- personally I don't see any
useful path forward that supports threading in LLVM but does so without
support for *very basic* TLS. Note that we don't need more than some
pointers, and we don't need constructors, destructors, or any of the
other fanciness which remains widely unimplemented.
Reid Kleckner [Thu, 29 Jan 2015 00:41:44 +0000 (00:41 +0000)]
Add a Windows EH preparation pass that zaps resumes
If the personality is not a recognized MSVC personality function, this
pass delegates to the dwarf EH preparation pass. This chaining supports
people on *-windows-itanium or *-windows-gnu targets.
Currently this recognizes some personalities used by MSVC and turns
resume instructions into traps to avoid link errors. Even if cleanups
are not used in the source program, LLVM requires the frontend to emit a
code path that resumes unwinding after an exception. Clang does this,
and we get unreachable resume instructions. PR20300 covers cleaning up
these unreachable calls to resume.
Eric Christopher [Thu, 29 Jan 2015 00:19:42 +0000 (00:19 +0000)]
Remove getSubtargetImpl from AArch64ISelLowering and cache the
correct subtarget by passing it in during the constructor as
TargetLowering is Subtarget specific.
Eric Christopher [Thu, 29 Jan 2015 00:19:39 +0000 (00:19 +0000)]
Remove getSubtargetImpl from ARMISelLowering and cache the
correct subtarget by passing it in during the constructor as
TargetLowering is Subtarget specific.
Philip Reames [Wed, 28 Jan 2015 23:06:47 +0000 (23:06 +0000)]
Teach SplitBlockPredecessors how to handle landingpad blocks.
Patch by: Igor Laevsky <igor@azulsystems.com>
"Currently SplitBlockPredecessors generates incorrect code in case if basic block we are going to split has a landingpad. Also seems like it is fairly common case among it's users to conditionally call either SplitBlockPredecessors or SplitLandingPadPredecessors. Because of this I think it is reasonable to add this condition directly into SplitBlockPredecessors."
Frederic Riss [Wed, 28 Jan 2015 22:15:14 +0000 (22:15 +0000)]
[dsymutil] Gather the DIE tree child->parent relationships.
The libDebugInfo DIE parsing doesn't store these relationships, we have to
recompute them. This commit introduces the CompileUnit bookkeeping class to
store this data. It will be expanded with more fields in the future.
Frederic Riss [Wed, 28 Jan 2015 22:15:07 +0000 (22:15 +0000)]
Add DWARFUnit::getNumDIEs() and getDIEIndex()
Parsed DIEs are stored in a vector and that makes it easy to get their
indices. Having easy access to a DIE's index makes it possible to use
arrays or vectors to efficiently store/access DIE related information.
There's no test for that new functionality (I don't see how to test
it standalone), but it'll be used in a subsequent dsymutil commit.
Chandler Carruth [Wed, 28 Jan 2015 19:29:22 +0000 (19:29 +0000)]
[LPM] Try to work around a bug with local-dynamic TLS on PowerPC 64.
Sadly, this precludes optimizing it down to initial-exec or local-exec
when statically linking, and in general makes the code slower on PPC 64,
but there's nothing else for it until we can arrange to produce the
correct bits for the linker.
Lots of thanks to Ulirch for tracking this down and Bill for working on
the long-term fix to LLVM so that we can relegate this to old host
clang versions.
I'll be watching the PPC build bots to make sure this effectively
revives them.
Philip Reames [Wed, 28 Jan 2015 19:28:03 +0000 (19:28 +0000)]
Remove gc.root's performCustomLowering
This is a refactoring to restructure the single user of performCustomLowering as a specific lowering pass and remove the custom lowering hook entirely.
Before this change, the LowerIntrinsics pass (note to self: rename!) was essentially acting as a pass manager, but without being structured in terms of passes. Instead, it proxied calls to a set of GCStrategies internally. This adds a lot of conceptual complexity (i.e. GCStrategies are stateful!) for very little benefit. Since there's been interest in keeping the ShadowStackGC working, I extracting it's custom lowering pass into a dedicated pass and just added that to the pass order. It will only run for functions which opt-in to that gc.
I wasn't able to find an easy way to preserve the runtime registration of custom lowering functionality. Given that no user of this exists that I'm aware of, I made the choice to just remove that. If someone really cares, we can look at restoring it via dynamic pass registration in the future.
Note that despite the large diff, none of the lowering code actual changes. I added the framing needed to make it a pass and rename the class, but that's it.
Chris Bieneman [Wed, 28 Jan 2015 19:00:25 +0000 (19:00 +0000)]
Refactoring llvm command line parsing and option registration.
Summary:
The primary goal of this patch is to remove the need for MarkOptionsChanged(). That goal is accomplished by having addOption and removeOption properly sort the options.
This patch puts the new add and remove functionality on a CommandLineParser class that is a placeholder. Some of the functionality in this class will need to be merged into the OptionRegistry, and other bits can hopefully be in a better abstraction.
This patch also removes the RegisteredOptionList global, and the need for cl::Option objects to be linked list nodes.
The changes in CommandLineTest.cpp are required because these changes shift when we validate that options are not duplicated. Before this change duplicate options were only found during certain cl API calls (like cl::ParseCommandLine). With this change duplicate options are found during option construction.
Bjorn Steinbrink [Wed, 28 Jan 2015 16:35:59 +0000 (16:35 +0000)]
Fix LLVMSetMetadata and LLVMAddNamedMetadataOperand for single value MDNodes
Summary:
MetadataAsValue uses a canonical format that strips the MDNode if it
contains only a single constant value. This triggers an assertion when
trying to cast the value to a MDNode.
Simon Atanasyan [Wed, 28 Jan 2015 16:22:50 +0000 (16:22 +0000)]
[ELFYAML] Provide explicit value for relocation addendums in the test
The `Addend` is an optional field of the `Relocation` YAML record. But
we do not provide its default value while reading it from a YAML file
and so it might keep uninitialized.
I am going to fix the code by a separate commit. We might either make
this field mandatory (at least for .rela sections) or specify 0 as
a default value explicitly.
Hal Finkel [Wed, 28 Jan 2015 14:44:14 +0000 (14:44 +0000)]
Correct the AggressiveAntiDepBreaker's handling of subregisters defining super registers
As the AggressiveAntiDepBreaker iterated backward through a scheduling region,
we must leave super registers live through subregister definitions so that all
relevant subregister definitions are renamed together. The problem was that we
were also discarding sub-register use locations as the sub-registers are
redefined. The result is that we'd rename the super register along with some,
but not all, subregister definitions.
As demonstrated by this example, this is also somewhat unfortunate, because
there is actually no need to rename the super register in this case (it is
fully covered by later subregister definitions), but we don't seem to track
enough information here to exploit that either.
Thanks to Daniil Troshkov for reporting the issue. The debug outputs in this
commit message are from Daniil.
Reduce integer multiplication by a constant of the form k*2^c, where k is in {3,5,9} into a lea + shl. Previously it was only done for imulq on 64-bit platforms, but it makes sense for imull and 32-bit as well.
This includes two things:
1) Fix TCRETURNdi and TCRETURN64di patterns to check the right thing (LP64 as opposed to target bitness).
2) Allow LEA64_32 in MatchingStackOffset.
Sean Silva [Wed, 28 Jan 2015 10:36:41 +0000 (10:36 +0000)]
[docs] Use slightly more proper .rst markup
Again, I'd like to emphasize to everyone that this sort of markup change
is *not* what you should be concerned about when writing docs. Focus on
*content*.
I applaud Chandler for focusing on the fantastic content of this new
section!
Chandler Carruth [Wed, 28 Jan 2015 09:52:14 +0000 (09:52 +0000)]
[LPM] Rip all of ManagedStatic and ThreadLocal out of the pretty stack
tracing code.
Managed static was just insane overhead for this. We took memory fences
and external function calls in every path that pushed a pretty stack
frame. This includes a multitude of layers setting up and tearing down
passes, the parser in Clang, everywhere. For the regression test suite
or low-overhead JITs, this was contributing to really significant
overhead.
Even the LLVM ThreadLocal is really overkill here because it uses
pthread_{set,get}_specific logic, and has careful code to both allocate
and delete the thread local data. We don't actually want any of that,
and this code in particular has problems coping with deallocation. What
we want is a single TLS pointer that is valid to use during global
construction and during global destruction, any time we want. That is
exactly what every host compiler and OS we use has implemented for
a long time, and what was standardized in C++11. Even though not all of
our host compilers support the thread_local keyword, we can directly use
the platform-specific keywords to get the minimal functionality needed.
Provided this limited trial survives the build bots, I will move this to
Compiler.h so it is more widely available as a light weight if limited
alternative to the ThreadLocal class. Many thanks to David Majnemer for
helping me think through the implications across platforms and craft the
MSVC-compatible syntax.
The end result is *substantially* faster. When running llc in a tight
loop over a small IR file targeting the aarch64 backend, this improves
its performance by over 10% for me. It also seems likely to fix the
remaining regressions seen by JIT users with threading enabled.
This may actually have more impact on real-world compile times due to
the use of the pretty stack tracing utility throughout the rest of Clang
or LLVM, but I've not collected any detailed measurements.
Chandler Carruth [Wed, 28 Jan 2015 09:47:21 +0000 (09:47 +0000)]
[LPM] A targeted but somewhat horrible fix to the legacy pass manager's
querying of the pass registry.
The pass manager relies on the static registry of PassInfo objects to
perform all manner of its functionality. I don't understand why it does
much of this. My very vague understanding is that this registry is
touched both during static initialization *and* while each pass is being
constructed. As a consequence it is hard to make accessing it not
require a acquiring some lock. This lock ends up in the hot path of
setting up, tearing down, and invaliditing analyses in the legacy pass
manager.
On most systems you can observe this as a non-trivial % of the time
spent in 'ninja check-llvm'. However, I haven't really seen it be more
than 1% in extreme cases of compiling more real-world software,
including LTO.
Unfortunately, some of the GPU JITs are seeing this taking essentially
all of their time because they have very small IR running through
a small pass pipeline very many times (at least, this is the vague
understanding I have of it).
This patch tries to minimize the cost of looking up PassInfo objects by
leveraging the fact that the objects themselves are immutable and they
are allocated separately on the heap and so don't have their address
change. It also requires a change I made the last time I tried to debug
this problem which removed the ability to de-register a pass from the
registry. This patch creates a single access path to these objects
inside the PMTopLevelManager which memoizes the result of querying the
registry. This is somewhat gross as I don't really know if
PMTopLevelManager is the *right* place to put it, and I dislike using
a mutable member to memoize things, but it seems to work.
For long-lived pass managers this should completely eliminate
the cost of acquiring locks to look into the pass registry once the
memoized cache is warm. For 'ninja check' I measured about 1.5%
reduction in CPU time and in total time on a machine with 32 hardware
threads. For normal compilation, I don't know how much this will help,
sadly. We will still pay the cost while we populate the memoized cache.
I don't think it will hurt though, and for LTO or compiles with many
small functions it should still be a win. However, for tight loops
around a pass manager with many passes and small modules, this will help
tremendously. On the AArch64 backend I saw nearly 50% reductions in time
to complete 2000 cycles of spinning up and tearing down the pipeline.
Measurements from Owen of an actual long-lived pass manager show more
along the lines of 10% improvements.
Fold fcmp in cases where value is provably non-negative. By Arch Robison.
This patch folds fcmp in some cases of interest in Julia. The patch adds a function CannotBeOrderedLessThanZero that returns true if a value is provably not less than zero. I.e. the function returns true if the value is provably -0, +0, positive, or a NaN. The patch extends InstructionSimplify.cpp to fold instances of fcmp where:
- the predicate is olt or uge
- the first operand is provably not less than zero
- the second operand is zero
The motivation for handling these cases optimizing away domain checks for sqrt in Julia for common idioms such as sqrt(x*x+y*y)..
Chandler Carruth [Wed, 28 Jan 2015 04:57:56 +0000 (04:57 +0000)]
[LPM] Stop using the string based preservation API. It is an
abomination.
For starters, this API is incredibly slow. In order to lookup the name
of a pass it must take a memory fence to acquire a pointer to the
managed static pass registry, and then potentially acquire locks while
it consults this registry for information about what passes exist by
that name. This stops the world of LLVMs in your process no matter
how little they cared about the result.
To make this more joyful, you'll note that we are preserving many passes
which *do not exist* any more, or are not even analyses which one might
wish to have be preserved. This means we do all the work only to say
"nope" with no error to the user.
String-based APIs are a *bad idea*. String-based APIs that cannot
produce any meaningful error are an even worse idea. =/
I have a patch that simply removes this API completely, but I'm hesitant
to commit it as I don't really want to perniciously break out-of-tree
users of the old pass manager. I'd rather they just have to migrate to
the new one at some point. If others disagree and would like me to kill
it with fire, just say the word. =]
Chandler Carruth [Wed, 28 Jan 2015 03:04:54 +0000 (03:04 +0000)]
Introduce a section to the programmers manual about type hierarchies,
polymorphism, and virtual dispatch.
This is essentially trying to explain the emerging design techniques
being used in LLVM these days somewhere more accessible than the
comments on a particular piece of infrastructure. It covers the
"concepts-based polymorphism" that caused some confusion during initial
reviews of the new pass manager as well as the tagged-dispatch mechanism
used pervasively in LLVM and Clang.
Perhaps most notably, I've tried to provide some criteria to help
developers choose between these options when designing new pieces of
infrastructure.
projects / llvm / log