- Jul 29, 2013
-
-
Nico Rieck authored
Single-slash encoded entries do not require a terminating null. This bumps the maximum table size from ~1MB to ~9.5MB. llvm-svn: 187352
-
NAKAMURA Takumi authored
llvm-svn: 187351
-
Benjamin Kramer authored
PR16721. llvm-svn: 187350
-
Silviu Baranga authored
Allow generation of vmla.f32 instructions when targeting Cortex-A15. The patch also adds the VFP4 feature to Cortex-A15 and fixes the DontUseFusedMAC predicate so that we can still generate vmla.f32 instructions on non-darwin targets with VFP4. llvm-svn: 187349
-
Robert Lytton authored
llvm-svn: 187348
-
Chandler Carruth authored
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
-
Daniel Jasper authored
llvm-svn: 187346
-
Daniel Jasper authored
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
-
Craig Topper authored
Return ExprError if both arguments to the mask form of __builtin_shufflvector don't have the same number of elements or the mask isn't an integer vector. 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
-
Tobias Grosser authored
This flags was not used in the test case, but caused failures when LLVM was built without debugging. We can savely remove it. llvm-svn: 187343
-
Tobias Grosser authored
llvm-svn: 187342
-
Tobias Grosser authored
llvm-svn: 187341
-
Nadav Rotem authored
llvm-svn: 187340
-
Tobias Grosser authored
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
-
Tobias Grosser authored
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
-
NAKAMURA Takumi authored
llvm-svn: 187337
-
Rafael Espindola authored
llvm-svn: 187336
-
Chandler Carruth authored
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
-
- Jul 28, 2013
-
-
Craig Topper authored
llvm-svn: 187334
-
Craig Topper authored
Remove use of sprintf added to X86 disassembler tablegen code. Send message with instruction name to errs() instead and use a generic message for the llvm_unreachable. Consistent with other places in this file. llvm-svn: 187333
-
Howard Hinnant authored
llvm-svn: 187332
-
Aaron Ballman authored
llvm-svn: 187331
-
Rafael Espindola authored
It was still failing with double quotes: http://bb.pgr.jp/builders/clang-i686-msys/builds/698/steps/test_clang/logs/Clang%20%3A%3A%20Driver__cl.c llvm-svn: 187330
-
Rafael Espindola authored
Should fix some of the bots that have assertions disabled. llvm-svn: 187329
-
Rafael Espindola authored
When first updating this test I only noticided the first RUN line. llvm-svn: 187328
-
Chandler Carruth authored
I forgot that we had two totally independent things here. :: sigh :: llvm-svn: 187327
-
Tobias Grosser authored
llvm-svn: 187326
-
Elena Demikhovsky authored
llvm-svn: 187325
-
Elena Demikhovsky authored
Added 512-bit operands printing. Added instruction formats for KNL instructions. llvm-svn: 187324
-
Chandler Carruth authored
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
-
Chandler Carruth authored
useful in a subsequent patch, but causes an unfortunate amount of noise, so I pulled it out into a separate patch. llvm-svn: 187322
-
Rui Ueyama authored
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
-
Bill Schmidt authored
llvm-svn: 187320
-
Bill Schmidt authored
llvm-svn: 187319
-
Bill Schmidt authored
The tests !defined(__ppc__) && !defined(__powerpc__) are not needed or helpful when verifying that code is being compiled for a 64-bit target. The simpler test provided by this revision is sufficient to tell if the target is 64-bit. llvm-svn: 187318
-
Rui Ueyama authored
llvm-svn: 187317
-
Nadav Rotem authored
llvm-svn: 187316
-
- Jul 27, 2013
-
-
Bob Wilson authored
Beginning with svn r186971, we noticed an internal test started to fail when using clang built with LTO. After much investigation, it turns out that there are no blatant bugs here, we are just running out of stack space and crashing. Preprocessor::ReadFunctionLikeMacroArgs already has one vector of 64 Tokens, and r186971 added another. When built with LTO, that function is inlined into Preprocessor::HandleMacroExpandedIdentifier, which for our internal test is invoked in a deep recursive cycle. I'm leaving the original 64 Token vector alone on the assumption that it is important for performance, but the new FixedArgTokens vector is only used on an error path, so it should be OK if it requires additional heap storage. It would be even better if we could avoid the deep recursion, but I think this change is a good thing to do regardless. <rdar://problem/14540345> llvm-svn: 187315
-
Michael Gottesman authored
IEEE-754R 1.4 Exclusions states that IEEE-754R does not specify the interpretation of the sign of NaNs. In order to remove an irrelevant variable that most floating point implementations do not use, standardize add, sub, mul, div, mod so that operating anything with NaN always yields a positive NaN. In a later commit I am going to update the APIs for creating NaNs so that one can not even create a negative NaN. llvm-svn: 187314
-
Michael Gottesman authored
Zeroing the significand of a floating point number does not necessarily cause a floating point number to become finite non zero. For instance, if one has a NaN, zeroing the significand will cause it to become +/- infinity. llvm-svn: 187313
-