There are actually two debug modes:
1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1
This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations.
2. -D_LIBCPP_DEBUG2=0
This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity.
llvm-svn: 187369
The quotes (from r187330) didn't really help here, the trick was to disable
the test on MSYS builds. This removes those quotes, changes back the comment
to explain why /? has to be quoted specifically, and moves the REQUIRES
line to the top of the file because that's important.
llvm-svn: 187366
in LLDB that load the canonical frame address rather than a location list.
- Handles the simple case where a CFA can be pulled from the current stack frame.
- Fixes more than one hundred failing tests with gcc 4.8!
TODO: Use UnwindPlan::GetRowForFunctionOffset if the DWARFExpression needs
to be evaluated in a context analogous to a virtual unwind (perhaps using RegisterContextLLDB).
- Also adds some comments to DWARFCallFrameInfo whenever I got confused.
llvm-svn: 187361
This change add a new option command line option -for-compilers that allows the
user to enable multiple transforms automatically.
Another difference is that now all transforms are enabled by default.
llvm-svn: 187360
On windows, c:foo is a valid file path, but stat fails on just "c:". This
causes a problem for clang since its file manager wants to cache data about
the parent directory.
There are refactorings to be done in here, but this gives clang the correct
behavior and testing first.
Patch by Yunzhong Gao!
llvm-svn: 187359
32-bit symbols have "_" as global prefix, but when forming the name of
COMDAT sections this prefix is ignored. The current behavior assumes that
this prefix is always present which is not the case for 64-bit and names
are truncated.
llvm-svn: 187356
If no other operation is specified, 's' becomes an operation instead of an
modifier. The s operation just creates a symbol table. It is the same as
running ranlib.
We assume the archive was created by a sane ar (like llvm-ar or gnu ar) and
if the symbol table is present, then it is current. We use that to optimize
the most common case: a broken build system that thinks it has to run ranlib.
llvm-svn: 187353
infrastructure to do promotion without a domtree the same smarts about
looking through GEPs, bitcasts, etc., that I just taught mem2reg about.
This way, if SROA chooses to promote an alloca which still has some
noisy instructions this code can cope with them.
I've not used as principled of an approach here for two reasons:
1) This code doesn't really need it as we were already set up to zip
through the instructions used by the alloca.
2) I view the code here as more of a hack, and hopefully a temporary one.
The SSAUpdater path in SROA is a real sore point for me. It doesn't make
a lot of architectural sense for many reasons:
- We're likely to end up needing the domtree anyways in a subsequent
pass, so why not compute it earlier and use it.
- In the future we'll likely end up needing the domtree for parts of the
inliner itself.
- If we need to we could teach the inliner to preserve the domtree. Part
of the re-work of the pass manager will allow this to be very powerful
even in large SCCs with many functions.
- Ultimately, computing a domtree has gotten significantly faster since
the original SSAUpdater-using code went into ScalarRepl. We no longer
use domfrontiers, and much of domtree is lazily done based on queries
rather than eagerly.
- At this point keeping the SSAUpdater-based promotion saves a total of
0.7% on a build of the 'opt' tool for me. That's not a lot of
performance given the complexity!
So I'm leaving this a bit ugly in the hope that eventually we just
remove all of this nonsense.
I can't even readily test this because this code isn't reachable except
through SROA. When I re-instate the patch that fast-tracks allocas
already suitable for promotion, I'll add a testcase there that failed
before this change. Before that, SROA will fix any test case I give it.
llvm-svn: 187347
This is the first version of a possible clang-tidy architecture. The
purpose of clang-tidy is to detect errors in adhering to common coding
patterns, e.g. described in the LLVM Coding Standards.
This is still heavily in flux.
Review: http://llvm-reviews.chandlerc.com/D884
llvm-svn: 187345
Previously a diagnostic was issued, but the code went ahead and built the ShuffleVectorExpr. While I'm here also simplify a couple lines by wrapping the return ExprError around the Diag calls.
llvm-svn: 187344
In case we detect that the schedule the user wants to import is invalid we
refuse it _and_ free the isl_maps containing it.
Another bug found thanks to Rafael.
llvm-svn: 187339
We now use __isl_take to annotate the uses of the isl_set where we got the
memory management wrong.
Thanks to Rafael! His pipefail work hardened our test environment and exposed
this bug nicely.
llvm-svn: 187338
standards for LLVM. Remove duplicated comments on the interface from the
implementation file (implementation comments are left there of course).
Also clean up, re-word, and fix a few typos and errors in the commenst
spotted along the way.
This is in preparation for changes to these files and to keep the
uninteresting tidying in a separate commit.
llvm-svn: 187335
uses of an alloca, we can pre-compute promotability while analyzing an
alloca for splitting in SROA. That lets us short-circuit the common case
of a bunch of trivially promotable allocas. This cuts 20% to 30% off the
run time of SROA for typical frontend-generated IR sequneces I'm seeing.
It gets the new SROA to within 20% of ScalarRepl for such code. My
current benchmark for these numbers is PR15412, but it fits the general
pattern of IR emitted by Clang so it should be widely applicable.
llvm-svn: 187323
Member functions to read the symbol table had too many parameters to propagate
all the temporary information from one to another. By storing the information
to data members, we can simplify the function signatures and improve the
readability.
llvm-svn: 187321
John Thompson