For OS X builds, we generate one version of config.h but then build for
multiple architectures. This means that the LLVM_HOSTTRIPLE setting may have
the wrong architecture. Adjust it dynamically to match the current
architecture. <rdar://problem/12715470>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169405 91177308-0d34-0410-b5e6-96231b3b80d8
A MachineInstr can only ever be constructed by CreateMachineInstr() and
CloneMachineInstr(), and those factories don't use the removed
constructors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169395 91177308-0d34-0410-b5e6-96231b3b80d8
This is for the lldb team so most of but not all of the values are
to be printed as hex with this option. Some small values like the
scale in an X86 address were requested to printed in decimal
without the leading 0x.
There may be some tweaks need to places that may still be in
decimal that they want in hex. Specially for arm. I made my best
guess. Any tweaks from here should be simple.
I also did the best I know now with help from the C++ gurus
creating the cleanest formatImm() utility function and containing
the changes. But if someone has a better idea to make something
cleaner I'm all ears and game for changing the implementation.
rdar://8109283
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169393 91177308-0d34-0410-b5e6-96231b3b80d8
- fixed ordering of calls to doFinalization to be the reverse of the pass run order due to potential dependencies
- fixed machine module info to operate in the doInitialization/doFinalization model, also fixes some FIXMEs
reviewed by Evan Cheng <evan.cheng@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169391 91177308-0d34-0410-b5e6-96231b3b80d8
reduction variable is not used outside the loop then we ran into an
endless loop. This change checks if we found the original PHI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169324 91177308-0d34-0410-b5e6-96231b3b80d8
This change attempts to simplify (X^Y) -> X or Y in the user's context if we know that
only bits from X or Y are demanded.
A minimized case is provided bellow. This change will simplify "t>>16" into "var1 >>16".
=============================================================
unsigned foo (unsigned val1, unsigned val2) {
unsigned t = val1 ^ 1234;
return (t >> 16) | t; // NOTE: t is used more than once.
}
=============================================================
Note that if the "t" were used only once, the expression would be finally optimized as well.
However, with with this change, the optimization will take place earlier.
Reviewed by Nadav, Thanks a lot!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169317 91177308-0d34-0410-b5e6-96231b3b80d8
The count attribute is more accurate with regards to the size of an array. It
also obviates the upper bound attribute in the subrange. We can also better
handle an unbound array by setting the count to -1 instead of the lower bound to
1 and upper bound to 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169312 91177308-0d34-0410-b5e6-96231b3b80d8
This reapplies the fix for PR13303 now with more justification. Based on my
execution of the GDB 7.5 test suite this results in:
expected passes: 16101 -> 20890 (+30%)
unexpected failures: 4826 -> 637 (-77%)
There are 23 checks that used to pass and now fail. They are all in
gdb.reverse. Investigating a few looks like they were accidentally passing
due to extra breakpoints being set by this bug. They're generally due to the
difference in end location between gcc and clang, the test suite is trying to
set breakpoints on the closing '}' that clang doesn't associate with any
instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169304 91177308-0d34-0410-b5e6-96231b3b80d8
textually as NativeClient. Also added a link to the native client project for
readers unfamiliar with it.
A Clang patch will follow shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169291 91177308-0d34-0410-b5e6-96231b3b80d8
on 64-bit PowerPC ELF.
The patch includes code to handle external assembly and MC output with the
integrated assembler. It intentionally does not support the "old" JIT.
For the initial-exec TLS model, the ABI requires the following to calculate
the address of external thread-local variable x:
Code sequence Relocation Symbol
ld 9,x@got@tprel(2) R_PPC64_GOT_TPREL16_DS x
add 9,9,x@tls R_PPC64_TLS x
The register 9 is arbitrary here. The linker will replace x@got@tprel
with the offset relative to the thread pointer to the generated GOT
entry for symbol x. It will replace x@tls with the thread-pointer
register (13).
The two test cases verify correct assembly output and relocation output
as just described.
PowerPC-specific selection node variants are added for the two
instructions above: LD_GOT_TPREL and ADD_TLS. These are inserted
when an initial-exec global variable is encountered by
PPCTargetLowering::LowerGlobalTLSAddress(), and later lowered to
machine instructions LDgotTPREL and ADD8TLS. LDgotTPREL is a pseudo
that uses the same LDrs support added for medium code model's LDtocL,
with a different relocation type.
The rest of the processing is straightforward.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169281 91177308-0d34-0410-b5e6-96231b3b80d8
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169224 91177308-0d34-0410-b5e6-96231b3b80d8
The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169218 91177308-0d34-0410-b5e6-96231b3b80d8
Added the code that actually performs the if-conversion during vectorization.
We can now vectorize this code:
for (int i=0; i<n; ++i) {
unsigned k = 0;
if (a[i] > b[i]) <------ IF inside the loop.
k = k * 5 + 3;
a[i] = k; <---- K is a phi node that becomes vector-select.
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169217 91177308-0d34-0410-b5e6-96231b3b80d8
The type of shirt-right (logical or arithemetic) should remain unchanged
when transforming "X << C1 >> C2" into "X << (C1-C2)"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169209 91177308-0d34-0410-b5e6-96231b3b80d8
the alignment is clamped to TargetFrameLowering.getStackAlignment if the target
does not support stack realignment or the option "realign-stack" is off.
This will cause miscompile if the address is treated as aligned and add is
replaced with or in DAGCombine.
Added a bool StackRealignable to TargetFrameLowering to check whether stack
realignment is implemented for the target. Also added a bool RealignOption
to MachineFrameInfo to check whether the option "realign-stack" is on.
rdar://12713765
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169197 91177308-0d34-0410-b5e6-96231b3b80d8
These functions have been replaced by TRI::getRegAllocationHints() which
provides the same capabilities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169192 91177308-0d34-0410-b5e6-96231b3b80d8
Now that there can be multiple hint registers from targets, it doesn't
make sense to have a function that returns 'the' preferred register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169190 91177308-0d34-0410-b5e6-96231b3b80d8
Targets can provide multiple hints now, so getRegAllocPref() doesn't
make sense any longer because it only returns one preferred register.
Replace it with getSimpleHint() in the remaining heuristics. This
function only
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169188 91177308-0d34-0410-b5e6-96231b3b80d8
No functional change for this commit. The follow-up patch will add more stuff to
these functions.
rdar://12713765
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169186 91177308-0d34-0410-b5e6-96231b3b80d8
Virtual registers with a known preferred register are prioritized by
RAGreedy. This function makes the condition explicit without depending
on getRegAllocPref().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169179 91177308-0d34-0410-b5e6-96231b3b80d8
This small change adds support for that. It will make all MCJIT tests pass
in make-check on BigEndian platforms.
Patch by Petar Jovanovic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169178 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds endian-awareness to MipsJITInfo and emitWordLE in
MipsCodeEmitter has become emitWord now to support both endianness.
Patch by Petar Jovanovic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169177 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies the hinting code quite a bit while making the targets
easier to write at the same time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169173 91177308-0d34-0410-b5e6-96231b3b80d8
This provides the same functionality as getRawAllocationOrder() for the
even/odd hints, but without the many constant register arrays.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169169 91177308-0d34-0410-b5e6-96231b3b80d8
"Windows.h" includes <Windows.h> which defines a bunch of stuff it shouldn't
(even with all the restriction macros). We have no control over this file, so
make it's scope as small as possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169165 91177308-0d34-0410-b5e6-96231b3b80d8
The TargetRegisterInfo::getRegAllocationHints() function is going to
replace the existing mechanisms for providing target-dependent hints to
the register allocator: ResolveRegAllocHint() and
getRawAllocationOrder().
The new hook is more flexible because it allows the target to provide
multiple preferred candidate registers for each virtual register, and it
is easier to use because targets are not required to return a reference
to a constant array like getRawAllocationOrder().
An optional VirtRegMap argument can be used to provide target-dependent
hints that depend on the provisional assignments of other virtual
registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169154 91177308-0d34-0410-b5e6-96231b3b80d8
which is the legality of the if-conversion transformation. The next step is to
implement the cost-model for the if-converted code as well as the
vectorization itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169152 91177308-0d34-0410-b5e6-96231b3b80d8
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
The partitioning logic attempted to handle uses of an alloca with an
offset starting before the alloca so long as the use had some overlap
with the alloca itself. However, there was a bug where we tested
'(uint64_t)Offset >= AllocSize' without first checking whether 'Offset'
was positive. As a consequence, essentially every negative offset (that
is, starting *before* the alloca does) would be thrown out, even if it
was overlapping. The subsequent code to throw out negative offsets which
were actually non-overlapping was essentially dead. The code to *handle*
overlapping negative offsets was actually dead!
I've just removed all of this, and taught SROA to discard any uses which
start prior to the alloca from the beginning. It has the lovely property
of simplifying the code. =] All the tests still pass, and in fact no new
tests are needed as this is already covered by our testsuite. Fixing the
code so that negative offsets work the way the comments indicate they
were supposed to work causes regressions. That's how I found this.
Anyways, this is all progress in the correct direction -- tightening up
SROA to be maximally aggressive. Some day, I really hope to turn
out-of-bounds accesses to an alloca into 'unreachable'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169120 91177308-0d34-0410-b5e6-96231b3b80d8
Also check in a case to repeat the issue, on which 'opt -globalopt' consumes 1.6GB memory.
The big memory footprint cause is that current GlobalOpt one by one hoists and stores the leaf element constant into the global array, in each iteration, it recreates the global array initializer constant and leave the old initializer alone. This may result in many obsolete constants left.
For example: we have global array @rom = global [16 x i32] zeroinitializer
After the first element value is hoisted and installed: @rom = global [16 x i32] [ 1, 0, 0, ... ]
After the second element value is installed: @rom = global [16 x 32] [ 1, 2, 0, 0, ... ] // here the previous initializer is obsolete
...
When the transform is done, we have 15 obsolete initializers left useless.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169079 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-30-misched-dbg.ll had crashed. Then (MDNode)N was "!{}".
I am not sure it would be ill-formed or not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169074 91177308-0d34-0410-b5e6-96231b3b80d8
- Each macro instantiation introduces a new buffer, and FindBufferForLoc() is
linear, so previously macro instantiation could be N^2 for some pathological
inputs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169073 91177308-0d34-0410-b5e6-96231b3b80d8
The TwoAddressInstructionPass takes the machine code out of SSA form by
expanding REG_SEQUENCE instructions into copies. It is no longer
necessary to rewrite the registers used by a REG_SEQUENCE instruction
because the new coalescer algorithm can do it now.
REG_SEQUENCE is just converted to a sequence of sub-register copies now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169067 91177308-0d34-0410-b5e6-96231b3b80d8
part of the compile unit CU and start separating out information into
the various sections that will be pulled out later.
WIP.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169061 91177308-0d34-0410-b5e6-96231b3b80d8
MachineCopyPropagation doesn't understand super-register liveness well
enough to be able to remove implicit defs of super-registers.
This fixes a problem in ARM/2012-01-26-CopyPropKills.ll that is exposed
by an future TwoAddressInstructionPass change. The KILL instructions are
removed before the machine code is emitted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169060 91177308-0d34-0410-b5e6-96231b3b80d8
uses. APFloat::convert() takes the pointer to the fltSemantics
variable, which is later accessed it in ~APFloat() desctructor.
That is, semantics must still be alive at the moment we delete
APFloat.
Found by experimental AddressSanitizer use-after-scope checker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169047 91177308-0d34-0410-b5e6-96231b3b80d8
The original patch removed a bunch of code that the SjLjEHPrepare pass placed
into the entry block if all of the landing pads were removed during the
CodeGenPrepare class. The more natural way of doing things is to run the CGP
*before* we run the SjLjEHPrepare pass.
Make it so!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169044 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids unidentified duplicates in the pass execution time report
when a pass runs more than once in the pass manager pipeline.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169039 91177308-0d34-0410-b5e6-96231b3b80d8
Codegen was failing with an assertion because of unexpected vector
operands when legalizing the selection DAG for a MUL instruction.
The asserting code was legalizing multiplies for vectors of size 128
bits. It uses a custom lowering to try and detect cases where it can
use a VMULL instruction instead of a VMOVL + VMUL. The code was
looking for input operands to the MUL that had been sign or zero
extended. If it found the extended operands it would drop the
sign/zero extension and use the original vector size as input to a
VMULL instruction.
The code assumed that the original input vector was 64 bits so that
after dropping the extension it would fit directly into a D register
and could be used as an operand of a VMULL instruction. The input
code that trigger the failure used a vector of <4 x i8> that was
sign extended to <4 x i32>. It was not safe to drop the sign
extension in this case because the original vector is only 32 bits
wide. The fix is to insert a sign extension for the vector to reach
the required 64 bit size. In this particular example, the vector would
need to be sign extented to a <4 x i16>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169024 91177308-0d34-0410-b5e6-96231b3b80d8
instruction (vmaddfp) to conform with IEEE to ensure the sign of a zero
result when resulting product is -0.0.
The -0.0 vector addend to vmaddfp is generated by a creating a vector
with full bits sets and then shifting each elements by 31-bits to the
left, resulting in a vector of 0x80000000 (or -0.0 as float).
The 'buildvec_canonicalize.ll' was adjusted to reflect this change and
the 'vec_mul.ll' was complemented with the float vector multiplication
test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168998 91177308-0d34-0410-b5e6-96231b3b80d8
Rationale:
1) This was the name in the comment block. ;]
2) It matches Clang's __has_feature naming convention.
3) It matches other compiler-feature-test conventions.
Sorry for the noise. =]
I've also switch the comment block to use a \brief tag and not duplicate
the name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168996 91177308-0d34-0410-b5e6-96231b3b80d8
For example, don't allow empty strings to be passed to getInt.
Move asserts inside parseSpecifier. (One day we may want to pass parse
error messages to the user - from LLParser - instead of using asserts,
but keep the code simple until then. There have been an attempt to do
this. See r142288, which got reverted, and r142605.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168991 91177308-0d34-0410-b5e6-96231b3b80d8
We're iterating over a non-deterministically ordered container looking
for two saturating flags. To do this correctly, we have to saturate
both, and only stop looping if both saturate to their final value.
Otherwise, which flag we see first changes the result.
This is also a micro-optimization of the previous version as now we
don't go into the (possibly expensive) test logic once the first
violation of either constraint is detected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168989 91177308-0d34-0410-b5e6-96231b3b80d8
functionality changed.
Evan's commit r168970 moved the code that the primary comment in this
function referred to to the other end of the function without moving the
comment, and there has been a steady creep of "boolean" logic in it that
is simpler if handled via early exit. That way each special case can
have its own comments. I've also made the variable name a bit more
explanatory than "AllFit". This is in preparation to fix the
non-deterministic output of this function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168988 91177308-0d34-0410-b5e6-96231b3b80d8
The simplify-libcalls pass maintained a statistic to count the number
of library calls that have been simplified. Now that library call
simplification is being carried out in instcombine the statistic should
be moved to there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168975 91177308-0d34-0410-b5e6-96231b3b80d8
depends on the IR infrastructure, there is no sense in it being off in
Support land.
This is in preparation to start working to expand InstVisitor into more
special-purpose visitors that are still generic and can be re-used
across different passes. The expansion will go into the Analylis tree
though as nothing in VMCore needs it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168972 91177308-0d34-0410-b5e6-96231b3b80d8
the tables cannot fit in registers (i.e. bitmap), do not emit the table
if it's using an illegal type.
rdar://12779436
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168970 91177308-0d34-0410-b5e6-96231b3b80d8
more information for dependences between
instructions that don't share a common loop.
Updated the test results appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168965 91177308-0d34-0410-b5e6-96231b3b80d8
This revision attempts to recognize following population-count pattern:
while(a) { c++; ... ; a &= a - 1; ... },
where <c> and <a>could be used multiple times in the loop body.
TODO: On X8664 and ARM, __buildin_ctpop() are not expanded to a efficent
instruction sequence, which need to be improved in the following commits.
Reviewed by Nadav, really appreciate!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168931 91177308-0d34-0410-b5e6-96231b3b80d8
the last invoke instruction in the function. This also removes the last landing
pad in an function. This is fine, but with SjLj EH code, we've already placed a
bunch of code in the 'entry' block, which expects the landing pad to stick
around.
When we get to the situation where CGP has removed the last landing pad, go
ahead and nuke the SjLj instructions from the 'entry' block.
<rdar://problem/12721258>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168930 91177308-0d34-0410-b5e6-96231b3b80d8
This patch migrates the puts optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
All the simplifiers from simplify-libcalls have now been migrated to
instcombine. Yay! Just a few other bits to migrate (prototype attribute
inference and a few statistics) and simplify-libcalls can finally be put
to rest.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168925 91177308-0d34-0410-b5e6-96231b3b80d8
MachOObjectFile owns a MachOObj, but never frees it. Both MachOObjectFile
and MachOObj want to own the MemoryBuffer, though, so we have to be careful
and give them each one of their own.
Thanks to Greg Clayton, Eric Christopher and Michael Spencer for helping
figure out what's going wrong here.
rdar://12561773
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168923 91177308-0d34-0410-b5e6-96231b3b80d8
This patch migrates the fputs optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168893 91177308-0d34-0410-b5e6-96231b3b80d8
This patch migrates the fwrite optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168892 91177308-0d34-0410-b5e6-96231b3b80d8
This patch migrates the fprintf optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168891 91177308-0d34-0410-b5e6-96231b3b80d8
The old version failed on a 3-arg instruction with (-1, 0, 0) shadows (it would
pick the 3rd operand origin irrespective of its shadow).
The new version always picks the origin of the rightmost poisoned operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168887 91177308-0d34-0410-b5e6-96231b3b80d8
This was found by MSVC10's STL debug mode on a test from the test suite. Sadly
std::is_heap isn't standard so there is no way to assert this without writing
our own heap verify, which looks like overkill to me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168885 91177308-0d34-0410-b5e6-96231b3b80d8
If we need to split the operand of a VSELECT, it must be the mask operand. We
split the entire VSELECT operand with EXTRACT_SUBVECTOR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168883 91177308-0d34-0410-b5e6-96231b3b80d8
For some targets, it is desirable to prefer scalarizing <N x i1> instead of promoting to a larger legal type, such as <N x i32>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168882 91177308-0d34-0410-b5e6-96231b3b80d8
This change ensures that shadow memory accesses have the same alignment
as corresponding app memory accesses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168880 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite getOriginPtr in a way that lets subsequent optimizations factor out
the common part of Shadow and Origin address calculation. Improves perf by
up to 5%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168879 91177308-0d34-0410-b5e6-96231b3b80d8
This was already done for memmove, where it is required for correctness.
This change improves performance by avoiding copyingthe same memory twice.
Also, the library functions are given __msan_ prefix to prevent instcombine
pass from converting them back to intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168876 91177308-0d34-0410-b5e6-96231b3b80d8
This could cause miscompilations in targets where sub-register
composition is not always idempotent (ARM).
<rdar://problem/12758887>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168837 91177308-0d34-0410-b5e6-96231b3b80d8
Also a couple not-user-visible changes; using empty() instead of size(), and
make inSection() not insert NULL Regex*'s into StringMap when doing a lookup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168833 91177308-0d34-0410-b5e6-96231b3b80d8
No functional change, just moved header files.
Targets can inject custom passes between register allocation and
rewriting. This makes it possible to tweak the register allocation
before rewriting, using the full global interference checking available
from LiveRegMatrix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168806 91177308-0d34-0410-b5e6-96231b3b80d8
appropriate unit tests. This change in itself is not expected to
affect any functionality at this point, but it will serve as a
stepping stone to improve FileCheck's variable matching capabilities.
Luckily, our regex implementation already supports backreferences,
although a bit of hacking is required to enable it. It supports both
Basic Regular Expressions (BREs) and Extended Regular Expressions
(EREs), without supporting backrefs for EREs, following POSIX strictly
in this respect. And EREs is what we actually use (rightly). This is
contrary to many implementations (including the default on Linux) of
POSIX regexes, that do allow backrefs in EREs.
Adding backref support to our EREs is a very simple change in the
regcomp parsing code. I fail to think of significant cases where it
would clash with existing things, and can bring more versatility to
the regexes we write. There's always the danger of a backref in a
specially crafted regex causing exponential matching times, but since
we mainly use them for testing purposes I don't think it's a big
problem. [it can also be placed behind a flag specific to FileCheck,
if needed].
For more details, see:
* http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/055840.html
* http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121126/156878.html
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168802 91177308-0d34-0410-b5e6-96231b3b80d8
The createPPCMCAsmInfo routine used PPC::R1 as the initial frame
pointer register, but on PPC64 the 32-bit R1 register does not
have a corresponding DWARF number, causing invalid CIE initial
frame state to be emitted. Fix by using PPC::X1 instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168799 91177308-0d34-0410-b5e6-96231b3b80d8
Accordingly, update a testcase with a broken datalayout string.
Also, we never parse negative numbers, because '-' is used as a
separator. Therefore, use unsigned as result type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168785 91177308-0d34-0410-b5e6-96231b3b80d8
This is for backwards compatibility for pre-3.x bc files. The code reads the
code, but does nothing with it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168779 91177308-0d34-0410-b5e6-96231b3b80d8
This is a simple, cheap infrastructure for analyzing the shape of a
DAG. It recognizes uniform DAGs that take the shape of bottom-up
subtrees, such as the included matrix multiplication example. This is
useful for heuristics that balance register pressure with ILP. Two
canonical expressions of the heuristic are implemented in scheduling
modes: -misched-ilpmin and -misched-ilpmax.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168773 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a hole in the "cheap" alias analysis logic implemented within
the DAG builder itself, regardless of whether proper alias analysis is
enabled. It now handles this pattern produced by LSR+CodeGenPrepare.
%sunkaddr1 = ptrtoint * %obj to i64
%sunkaddr2 = add i64 %sunkaddr1, %lsr.iv
%sunkaddr3 = inttoptr i64 %sunkaddr2 to i32*
store i32 %v, i32* %sunkaddr3
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168768 91177308-0d34-0410-b5e6-96231b3b80d8
When two instructions are combined into a vector instruction,
the resulting instruction must have the most-conservative flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168765 91177308-0d34-0410-b5e6-96231b3b80d8
The Target library is not allowed to depend on the large CodeGen
library, but the TRI and TII classes provide abstract interfaces that
require both caller and callee to link to CodeGen.
The implementation files for these classes provide default
implementations of some of the hooks. These methods may need to
reference CodeGen, so they belong in that library.
We already have a number of methods implemented in the
TargetInstrInfoImpl sub-class because of that. I will merge that class
into the parent next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168758 91177308-0d34-0410-b5e6-96231b3b80d8
When the CodeGenInfo is to be created for the PPC64 target machine,
a default code-model selection is converted to CodeModel::Medium
provided we are not targeting the Darwin OS. Defaults for Darwin
are unaffected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168747 91177308-0d34-0410-b5e6-96231b3b80d8
classes. The vast majority of the remaining issues are due to uses of
invalid registers, which are defined by getRegForValue(). Those will be
a little more challenging to cleanup.
rdar://12719844
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168735 91177308-0d34-0410-b5e6-96231b3b80d8
The SectionMemoryManager now supports (and requires) applying section-specific page permissions. Clients using this memory manager must call either MCJIT::finalizeObject() or SectionMemoryManager::applyPermissions() before executing JITed code.
See r168718 for changes from the previous implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168721 91177308-0d34-0410-b5e6-96231b3b80d8
there's no possible loo-independent dependence, then there's no
dependence.
Updated all test result appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168719 91177308-0d34-0410-b5e6-96231b3b80d8
boundaries.
Given the following case:
BB0
%vreg1<def> = SUBrr %vreg0, %vreg7
%vreg2<def> = COPY %vreg7
BB1
%vreg10<def> = SUBrr %vreg0, %vreg2
We should be able to CSE between SUBrr in BB0 and SUBrr in BB1.
rdar://12462006
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168717 91177308-0d34-0410-b5e6-96231b3b80d8
My commit to migrate the printf simplifiers from the simplify-libcalls
in r168604 introduced a regression reported by Duncan [1]. The problem
is that in some cases the library call simplifier can return a new value
that has no uses and the new value's type is different than the old value's
type (which is fine because there are no uses). The specific case that
triggered the bug looked something like:
declare void @printf(i8*, ...)
...
call void (i8*, ...)* @printf(i8* %fmt)
Which we want to optimized into:
call i32 @putchar(i32 104)
However, the code was attempting to replace all uses of the printf with
the putchar and the types differ, hence a crash. This is fixed by *just*
deleting the original instruction when there are no uses. The old
simplify-libcalls pass is already doing something similar.
[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/056338.html
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168716 91177308-0d34-0410-b5e6-96231b3b80d8
