llvm-svn: 244823

[modules] If loading a .pcm file would cause us to run out of source locations, attempt to fail more gracefully. (No test; this requires >= 4GB of preprocessed input...)

llvm-svn: 244822

To be clear: this is an *optimization* not a correctness change.

CodeGenPrep likes to duplicate icmps feeding branch instructions to take advantage of x86's ability to fuze many comparison/branch patterns into a single micro-op and to reduce the need for materializing i1s into general registers. PlaceSafepoints likes to place safepoint polls right at the end of basic blocks (immediately before terminators) when inserting entry and backedge safepoints. These two heuristics interact in a somewhat unfortunate way where the branch terminating the original block will be controlled by a condition driven by unrelocated pointers. This forces the register allocator to keep both the relocated and unrelocated values of the pointers feeding the icmp alive over the safepoint poll.

One simple fix would have been to just adjust PlaceSafepoints to move one back in the basic block, but you can reach similar cases as a result of LICM or other hoisting passes. As a result, doing a post insertion fixup seems to be more robust.

I considered doing this in CodeGenPrep itself, but having to update the live sets of already rewritten safepoints gets complicated fast. In particular, you can't just use def/use information because by moving the icmp, we're extending the live range of it's inputs potentially.

Instead, this patch teaches RewriteStatepointsForGC to make the required adjustments before making the relocations explicit in the IR. This change really highlights the fact that RSForGC is a CodeGenPrep-like pass which is performing target specific lowering. In the long run, we may even want to combine the two though this would require a lot more smarts to be integrated into RSForGC first. We currently rely on being able to run a set of cleanup passes post rewriting because the IR RSForGC generates is pretty damn ugly.

Differential Revision: http://reviews.llvm.org/D11819

llvm-svn: 244821

Revert "Implement poisoning of only class members in dtor, as opposed to also poisoning fields inherited from base classes."

This reverts commit 8dbbf3578a9a5d063232b59e558e5fe46e2cd42c.
Rolled back due to buildbot failures on 'ninja check-clang'.

llvm-svn: 244820

Implement poisoning of only class members in dtor, as opposed to also poisoning fields inherited from base classes.
Verify emitted code for derived class with virtual destructor sanitizes its members only once.
Changed emission order for dtor callback, so only the last dtor for a class emits the sanitizing callback, while ensuring that class members are poisoned before base class destructors are invoked.
Skip poisoning of members, if class has no fields.
Removed patch file containing extraneous changes.

Summary: Poisoning applied to only class members, and before dtors for base class invoked

Reviewers: eugenis, kcc

Differential Revision: http://reviews.llvm.org/D11951

llvm-svn: 244819

Summary: Fixed test in response to buildbot failures from last night.

Reviewers: eugenis, kcc

Differential Revision: http://reviews.llvm.org/D11992

llvm-svn: 244818

This commit fixes a bug where MI parser couldn't resolve the named IR
references that referenced named global values.

llvm-svn: 244817

llvm-svn: 244816

llvm-svn: 244815

This commit moves the code that parses the frame indices for the fixed stack
objects from the method 'parseFixedStackObjectOperand' to a new method named
'parseFixedStackFrameIndex', so that it can be reused when parsing fixed stack
pseudo source values.

llvm-svn: 244814

llvm-svn: 244813

Move the object being used to move-initialize when calling the base class' constructor from the ctor-initializer. This should have no effect given the triviality of the class, but it allows for easier maintenance should the semantics of the base class change. NFC intended.

llvm-svn: 244812

llvm-svn: 244811

llvm-svn: 244809

When rewriting the IR such that base pointers are available for every live pointer, we potentially need to duplicate instructions to propagate the base. The original code had only handled PHI and Select under the belief those were the only instructions which would need duplicated. When I added support for vector instructions, I'd added a collection of hacks for ExtractElement which caught most of the common cases. Of course, I then found the one test case my hacks couldn't cover. :)

This change removes all of the early hacks for extract element. By defining extractelement as a BDV (rather than trying to look through it), we can extend the rewriting algorithm to duplicate the extract as needed.  Note that a couple of peephole optimizations were left in for the moment, because while we now handle extractelement as a first class citizen, we're not yet handling insertelement.  That change will follow in the near future.  

llvm-svn: 244808

There was a missing implicit task init for the ICV PUSH case in hierarchical barrier.

llvm-svn: 244807

llvm-svn: 244806

llvm-svn: 244805

llvm-svn: 244804

llvm-svn: 244803

llvm-svn: 244802

Fix process_events.py to auto continue the process if we attached so the process doesn't just sit there suspended.

llvm-svn: 244801

llvm-svn: 244800

llvm-svn: 244799

llvm-svn: 244797

llvm-svn: 244795

llvm-svn: 244794

llvm-svn: 244793

llvm-svn: 244792

llvm-svn: 244791

llvm-svn: 244789

When displaying the macro backtrace, ignore some of the backtraces that do not
provide extra information to the diagnostic.  Typically, if the problem is
entirely contained within a macro argument, the macro expansion is often not
needed.  Also take into account SourceRange's attached to the diagnostic when
selecting which backtraces to ignore.  Two previous test cases have also been
updated.

Patch by Zhengkai Wu, with minor formatting fixes.

Differential Revision: http://reviews.llvm.org/D11778

llvm-svn: 244788

I forgot to add these in r244780 and r244778. Sorry about that.

Also order the static dependencies in a lexicographical order.

llvm-svn: 244787

Thanks to Majnemer for the help.

llvm-svn: 244786

AliasAnalysis.

Same as the other commits, the TLI access from an alias analysis is
going away and isn't very clean -- it is better to explicitly mark the
dependencies.

llvm-svn: 244785

Reviewers: zturner, clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D11846

llvm-svn: 244784

Reviewers: zturner

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D11910

llvm-svn: 244783

Reviewers: zturner

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D11909

llvm-svn: 244782

Summary: Update to D11816.

Reviewers: zturner

Subscribers: zturner, lldb-commits

Differential Revision: http://reviews.llvm.org/D11843

llvm-svn: 244781

just depend on it directly.

This was particularly frustrating because there was a really wide
mixture of using a member variable and re-extracting it from the AA that
happened to be around. I think the result is much more clear.

I've also deleted all of the pointless null checks and used references
across the APIs where I could to make it explicit that this cannot be
null in a useful fashion.

llvm-svn: 244780