- Feb 25, 2014
-
-
Logan Chien authored
The function with uwtable attribute might be visited by the stack unwinder, thus the link register should be considered as clobbered after the execution of the branch and link instruction (i.e. the definition of the machine instruction can't be ignored) even when the callee function are marked with noreturn. llvm-svn: 202165
-
Richard Osborne authored
The behaviour of the XCore's instruction buffer means that the performance of the same code sequence can differ depending on whether it starts at a 4 byte aligned address or not. Since we don't model the instruction buffer in the backend we have no way of knowing for sure if it is beneficial to word align a specific function. However, in the absence of precise modelling, it is better on balance to word align functions because: * It makes a fetch-nop while executing the prologue slightly less likely. * If we don't word align functions then a small perturbation in one function can have a dramatic knock on effect. If the size of the function changes it might change the alignment and therefore the performance of all the functions that happen to follow it in the binary. This butterfly effect makes it harder to reason about and measure the performance of code. llvm-svn: 202163
-
Rafael Espindola authored
llvm-svn: 202157
-
Rafael Espindola authored
llvm-svn: 202155
-
Chandler Carruth authored
just "load". This helps avoid pointless de-duping with order-sensitive numbers as we already have unique names from the original load. It also makes the resulting IR quite a bit easier to read. llvm-svn: 202140
-
Chandler Carruth authored
the pointer adjustment code. This is the primary code path that creates totally new instructions in SROA and being able to lump them based on the pointer value's name for which they were created causes *significantly* fewer name collisions and general noise in the debug output. This is particularly significant because it is making it much harder to track down instability in the output of SROA, as name de-duplication is a totally harmless form of instability that gets in the way of seeing real problems. The new fancy naming scheme tries to dig out the root "pre-SROA" name for pointer values and associate that all the way through the pointer formation instructions. Digging out the root is important to prevent the multiple iterative rounds of SROA from just layering too much cruft on top of cruft here. We already track the layers of SROAs iteration in the alloca name prefix. We don't need to duplicate it here. Should have no functionality change, and shouldn't have any really measurable impact on NDEBUG builds, as most of the complex logic is debug-only. llvm-svn: 202139
-
Chandler Carruth authored
PHI-pointer builder, just copy the builder and clobber the obvious fields. llvm-svn: 202136
-
Chandler Carruth authored
using OldPtr more heavily. Lots of this code was written before the rewriter had an OldPtr member setup ahead of time. There are already asserts in place that should ensure this doesn't change any functionality. llvm-svn: 202135
-
Chandler Carruth authored
llvm-svn: 202134
-
Nico Rieck authored
llvm-svn: 202130
-
Chandler Carruth authored
the break statement, not just think it to yourself.... No idea how this worked at all, much less survived most bots, my bootstrap, and some bot bootstraps! The Polly one didn't survive, and this was filed as PR18959. I don't have a reduced test case and honestly I'm not seeing the need. What we probably need here are better asserts / debug-build behavior in SmallPtrSet so that this madness doesn't make it so far. llvm-svn: 202129
-
Renato Golin authored
llvm-svn: 202127
-
Renato Golin authored
llvm-svn: 202126
-
Renato Golin authored
llvm-svn: 202125
-
Alexey Samsonov authored
llvm-svn: 202119
-
Alp Toker authored
llvm-svn: 202107
-
Chandler Carruth authored
sorting it. This helps uncover latent reliance on the original ordering which aren't guaranteed to be preserved by std::sort (but often are), and which are based on the use-def chain orderings which also aren't (technically) guaranteed. Only available in C++11 debug builds, and behind a flag to prevent noise at the moment, but this is generally useful so figured I'd put it in the tree rather than keeping it out-of-tree. llvm-svn: 202106
-
Chandler Carruth authored
the destination operand or source operand of a memmove. It so happens that it was impossible for SROA to try to rewrite self-memmove where the operands are *identical*, because either such a think is volatile (and we don't rewrite) or it is non-volatile, and we don't even register it as a use of the alloca. However, making the 'IsDest' test *rely* on this subtle fact is... Very confusing for the reader. We should use the direct and readily available test of the Use* which gives us concrete information about which operand is being rewritten. No functionality changed, I hope! ;] llvm-svn: 202103
-
Chandler Carruth authored
These complement many of the existing accessors and make it significantly easier to write code which needs to poke at the underlying Use without hard coding the operand number at which it resides for a particular instruction. No functionality changed of course. llvm-svn: 202102
-
Nick Lewycky authored
llvm-svn: 202096
-
Chandler Carruth authored
ordering. The fundamental problem that we're hitting here is that the use-def chain ordering is *itself* not a stable thing to be relying on in the rewriting for SROA. Further, we use a non-stable sort over the slices to arrange them based on the section of the alloca they're operating on. With a debugging STL implementation (or different implementations in stage2 and stage3) this can cause stage2 != stage3. The specific aspect of this problem fixed in this commit deals with the rewriting and load-speculation around PHIs and Selects. This, like many other aspects of the use-rewriting in SROA, is really part of the "strong SSA-formation" that is doen by SROA where it works very hard to canonicalize loads and stores in *just* the right way to satisfy the needs of mem2reg[1]. When we have a select (or a PHI) with 2 uses of the same alloca, we test that loads downstream of the select are speculatable around it twice. If only one of the operands to the select needs to be rewritten, then if we get lucky we rewrite that one first and the select is immediately speculatable. This can cause the order of operand visitation, and thus the order of slices to be rewritten, to change an alloca from promotable to non-promotable and vice versa. The fix is to defer all of the speculation until *after* the rewrite phase is done. Once we've rewritten everything, we can accurately test for whether speculation will work (once, instead of twice!) and the order ceases to matter. This also happens to simplify the other subtlety of speculation -- we need to *not* speculate anything unless the result of speculating will make the alloca fully promotable by mem2reg. I had a previous attempt at simplifying this, but it was still pretty horrible. There is actually already a *really* nice test case for this in basictest.ll, but on multiple STL implementations and inputs, we just got "lucky". Fortunately, the test case is very small and we can essentially build it in exactly the opposite way to get reasonable coverage in both directions even from normal STL implementations. llvm-svn: 202092
-
David Blaikie authored
llvm-svn: 202091
-
Rafael Espindola authored
No functionality change. Just reduces the noise of an upcoming patch. llvm-svn: 202087
-
- Feb 24, 2014
-
-
Bernard Ogden authored
Commit 201921 overrides setting of CMAKE_INSTALL_RPATH via the command line. Last time this happened we applied another patch to only set CMAKE_INSTALL_RPATH if already defined (r197825). This patch does the same thing again, but only for the UNIX case - we leave APPLE alone as presumably the original committer is happy with the non-overriding behaviour. llvm-svn: 202085
-
Albrecht Kadlec authored
llvm-svn: 202084
-
Simon Atanasyan authored
boundaries. It is possible to create an ELF executable where symbol from say .text section 'points' to the address outside the section boundaries. It does not have a sense to disassemble something outside the section. Without this fix llvm-objdump prints finite or infinite (depends on the executable file architecture) number of 'invalid instruction encoding' warnings. llvm-svn: 202083
-
Andrew Trick authored
See <rdar://16149106> [MCJIT] provide a platform-independent way to communicate callee-save frame info. <rdar://16149279> [MCJIT] get the host OS version from a runtime check, not a configure-time check. llvm-svn: 202082
-
Matt Arsenault authored
llvm-svn: 202080
-
Matt Arsenault authored
Does not yet include larger part required to match v_mad_i64_i32 / v_mad_u64_u32. llvm-svn: 202077
-
Matt Arsenault authored
The check is clearer as southern islands or later, rather than checking for later than northern islands. llvm-svn: 202076
-
Matt Arsenault authored
llvm-svn: 202075
-
Matt Arsenault authored
llvm-svn: 202074
-
Matt Arsenault authored
llvm-svn: 202073
-
Arnold Schwaighofer authored
Vectorize sequential stores of a broadcasted value. 5% on eon. radar://16124699 llvm-svn: 202067
-
Quentin Colombet authored
The patch defines new or refines existing generic scheduling classes to match the behavior of the SSE instructions. It also maps those scheduling classes on the related SSE instructions. <rdar://problem/15607571> llvm-svn: 202065
-
Roman Divacky authored
llvm-svn: 202057
-
Rafael Espindola authored
After this I will set the default back to F_None. The advantage is that before this patch forgetting to set F_Binary would corrupt a file on windows. Forgetting to set F_Text produces one that cannot be read in notepad, which is a better failure mode :-) llvm-svn: 202052
-
Arnold Schwaighofer authored
During the LTO phase LICM will move loop invariant global variables out of loops (informed by GlobalModRef). This makes more loops countable presenting opportunity for the loop vectorizer. Adding the loop vectorizer improves some TSVC benchmarks and twolf/ref dataset (5%) on x86-64. radar://15970632 llvm-svn: 202051
-
Rafael Espindola authored
llvm-svn: 202050
-
Reed Kotler authored
targets. Just big endian (mips-... and mips64-...) llvm-svn: 202049
-