| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
|  | 
llvm-svn: 189111
 | 
| | 
| 
| 
|  | 
llvm-svn: 189109
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
The code was erroneously reading overflow area shadow from the TLS slot,
bypassing the local copy. Reading shadow directly from TLS is wrong, because
it can be overwritten by a nested vararg call, if that happens before va_start.
llvm-svn: 189104
 | 
| | 
| 
| 
|  | 
llvm-svn: 189103
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This function attribute indicates that the function is not optimized
by any optimization or code generator passes with the 
exception of interprocedural optimization passes.
llvm-svn: 189101
 | 
| | 
| 
| 
| 
| 
|  | 
Just the instructions and intrinsics for now.
llvm-svn: 189100
 | 
| | 
| 
| 
| 
| 
|  | 
This allows us to make more use of the many compare reg,mem instructions.
llvm-svn: 189099
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
If we had a store of an integer to memory, and the integer and store size
were suitable for a form of MV..., we used MV... no matter what.  We could
then have sequences like:
    lay %r2, 0(%r3,%r4)
    mvi 0(%r2), 4
In these cases it seems better to force the constant into a register
and use a normal store:
    lhi %r2, 4
    stc %r2, 0(%r3, %r4)
since %r2 is more likely to be hoisted and is easier to rematerialize.
llvm-svn: 189098
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
...so that it can be used for z too.  Most of the code is the same.
The only real change is to use TargetTransformInfo to test when a sqrt
instruction is available.
The pass is opt-in because at the moment it only handles sqrt.
llvm-svn: 189097
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
I'd forgotten that "Requires" blocks override rather than add to the
constraints, so my pseudo-instruction was being selected in Thumb mode leading
to nonsense instructions.
rdar://problem/14817358
llvm-svn: 189096
 | 
| | 
| 
| 
| 
| 
|  | 
registers.
llvm-svn: 189095
 | 
| | 
| 
| 
|  | 
llvm-svn: 189091
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
This is a part of D1164. DWARFCompileUnit is not that lightweight
to copy it around, and we want it to own corresponding .dwo compile unit
eventually.
Reviewers: echristo
Reviewed By: echristo
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1298
llvm-svn: 189089
 | 
| | 
| 
| 
|  | 
llvm-svn: 189085
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This field specifies registers that are preserved across function calls,
but that should not be included in the generates SaveList array.
This can be used ot generate regmasks for architectures that save
registers through other means, like SPARC's register windows.
llvm-svn: 189084
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
stale to the point of not working and more resilient to debug info changes.
The current version of StripDeadDebugInfo became stale and no longer actually
worked since it was expecting an older version of debug info.
This patch updates it to use DebugInfoFinder and the modern DebugInfo classes as
much as possible to make it more redundent to such changes. Additionally, the
only place where that was avoided (the code where we replace the old sets with
the new), I call verify on the DIContextUnit implying that if the format changes
and my live set changes no longer make sense an assert will be hit. In order to
ensure that that occurs I have included a test case.
The actual stripping of the dead debug info follows the same strategy as was
used before in this class: find the live set and replace the old set in the
given compile unit (which may contain dead global variables/functions) with the
new live one.
llvm-svn: 189078
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
ARM by disabling does not return on __stack_chk_fail.
This is to fix the bots while I look to see if there is something I can do here.
rdar://14811848
llvm-svn: 189076
 | 
| | 
| 
| 
| 
| 
|  | 
assumed false.
llvm-svn: 189063
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This fixes a crash in Unigine Tropics.
https://bugs.freedesktop.org/show_bug.cgi?id=68389
llvm-svn: 189057
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
functions, and vice versa, with wrappers.
Differential Revision: http://llvm-reviews.chandlerc.com/D1442
llvm-svn: 189054
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: http://llvm-reviews.chandlerc.com/D1441
llvm-svn: 189053
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
DFSan changes the ABI of each function in the module.  This makes it possible
for a function with the native ABI to be called with the instrumented ABI,
or vice versa, thus possibly invoking undefined behavior.  A simple way
of statically detecting instances of this problem is to prepend the prefix
"dfs$" to the name of each instrumented-ABI function.
This will not catch every such problem; in particular function pointers passed
across the instrumented-native barrier cannot be used on the other side.
These problems could potentially be caught dynamically.
Differential Revision: http://llvm-reviews.chandlerc.com/D1373
llvm-svn: 189052
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This uses the ARMcmov pattern that Tim cleaned up in r188995.
Thanks to Simon Tatham for his floating point help!
llvm-svn: 189024
 | 
| | 
| 
| 
| 
| 
|  | 
contain Offset when Offset >= 65536.
llvm-svn: 189021
 | 
| | 
| 
| 
|  | 
llvm-svn: 189020
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The instruction to convert between floating point and fixed point representations
takes an immediate operand for the number of fractional bits of the fixed point
value. ARMARM specifies that when that number of bits is zero, the assembler
should encode floating point/integer conversion instructions. 
This patch adds the necessary instruction aliases to achieve this behaviour.
llvm-svn: 189009
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
using GEPs. Previously, it used a number of different heuristics for
analyzing the GEPs. Several of these were conservatively correct, but
failed to fall back to SCEV even when SCEV might have given a reasonable
answer. One was simply incorrect in how it was formulated.
There was good code already to recursively evaluate the constant offsets
in GEPs, look through pointer casts, etc. I gathered this into a form
code like the SLP code can use in a previous commit, which allows all of
this code to become quite simple.
There is some performance (compile time) concern here at first glance as
we're directly attempting to walk both pointers constant GEP chains.
However, a couple of thoughts:
1) The very common cases where there is a dynamic pointer, and a second
   pointer at a constant offset (usually a stride) from it, this code
   will actually not do any unnecessary work.
2) InstCombine and other passes work very hard to collapse constant
   GEPs, so it will be rare that we iterate here for a long time.
That said, if there remain performance problems here, there are some
obvious things that can improve the situation immensely. Doing
a vectorizer-pass-wide memoizer for each individual layer of pointer
values, their base values, and the constant offset is likely to be able
to completely remove redundant work and strictly limit the scaling of
the work to scrape these GEPs. Since this optimization was not done on
the prior version (which would still benefit from it), I've not done it
here. But if folks have benchmarks that slow down it should be straight
forward for them to add.
I've added a test case, but I'm not really confident of the amount of
testing done for different access patterns, strides, and pointer
manipulation.
llvm-svn: 189007
 | 
| | 
| 
| 
| 
| 
|  | 
we pass these tests with -verify-machineinstrs.
llvm-svn: 189006
 | 
| | 
| 
| 
|  | 
llvm-svn: 189005
 | 
| | 
| 
| 
| 
| 
| 
|  | 
The function call to external function should come with PLT relocation
type if the PIC relocation model is used.
llvm-svn: 189002
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
pointers, but accumulate the offset into an APInt in the process of
stripping it.
This is a pretty handy thing to have, such as when trying to determine
if two pointers are at some constant relative offset. I'll be committing
a patch shortly to use it for exactly that purpose.
llvm-svn: 189000
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Follow-up to r188903.
The AllocationGranularity can be 65536 on Win32, even on Cygwin.
llvm-svn: 188998
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Back in the mists of time (2008), it seems TableGen couldn't handle the
patterns necessary to match ARM's CMOV node that we convert select operations
to, so we wrote a lot of fairly hairy C++ to do it for us.
TableGen can deal with it now: there were a few minor differences to CodeGen
(see tests), but nothing obviously worse that I could see, so we should
probably address anything that *does* come up in a localised manner.
llvm-svn: 188995
 | 
| | 
| 
| 
| 
| 
| 
|  | 
The code for 'Q' and 'R' operand modifiers needs to look through tied
operands to discover the register class.
llvm-svn: 188990
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
parentmbb into a successmbb, include any DBG_VALUE MI.
Fix for PR16954.
llvm-svn: 188987
 | 
| | 
| 
| 
|  | 
llvm-svn: 188980
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Indirect tail-calls shouldn't use R9 for the branch destination, as
it's not reliably a call-clobbered register.
rdar://14793425
llvm-svn: 188967
 | 
| | 
| 
| 
|  | 
llvm-svn: 188957
 | 
| | 
| 
| 
|  | 
llvm-svn: 188956
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
When truncated vector stores were being custom lowered in
VectorLegalizer::LegalizeOp(), the old (illegal) and new (legal) node pair
was not being added to LegalizedNodes list.  Instead of the legalized
result being passed to VectorLegalizer::TranslateLegalizeResult(),
the result was being passed back into VectorLegalizer::LegalizeOp(),
which ended up adding a (new, new) pair to the list instead.
This was causing an assertion failure when a custom lowered truncated
vector store was the last instruction a basic block and the VectorLegalizer
was unable to find it in the LegalizedNodes list when updating the
DAG root.
llvm-svn: 188953
 | 
| | 
| 
| 
| 
| 
|  | 
Spotted by Bill Wendling.
llvm-svn: 188942
 | 
| | 
| 
| 
| 
| 
|  | 
Replace "(255 & value)" with "(0xFF & value)" to improve clarity.
llvm-svn: 188941
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The small utility function that pattern matches Base + Index +
Offset patterns for loads and stores fails to recognize the base
pointer for loads/stores from/into an array at offset 0 inside a
loop. As a result DAGCombiner::MergeConsecutiveStores was not able
to merge all stores.
This commit fixes the issue by adding an additional pattern match
and also a test case.
Reviewer: Nadav
llvm-svn: 188936
 | 
| | 
| 
| 
|  | 
llvm-svn: 188932
 | 
| | 
| 
| 
| 
| 
|  | 
Also obsessively reorder the headers to be in something closer to alphabetical order.
llvm-svn: 188928
 | 
| | 
| 
| 
|  | 
llvm-svn: 188926
 | 
| | 
| 
| 
|  | 
llvm-svn: 188925
 | 
| | 
| 
| 
|  | 
llvm-svn: 188924
 | 
| | 
| 
| 
|  | 
llvm-svn: 188916
 | 
| | 
| 
| 
|  | 
llvm-svn: 188915
 |