| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
------------------------------------------------------------------------
r195162 | arnolds | 2013-11-19 14:20:20 -0800 (Tue, 19 Nov 2013) | 12 lines
SLPVectorizer: Fix stale for Value pointer array
We are slicing an array of Value pointers and process those slices in a loop.
The problem is that we might invalidate a later slice by vectorizing a former
slice.
Use a WeakVH to track the pointer. If the pointer is deleted or RAUW'ed we can
tell.
The test case will only fail when running with libgmalloc.
radar://15498655
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195222 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
------------------------------------------------------------------------
r195161 | arnolds | 2013-11-19 14:20:18 -0800 (Tue, 19 Nov 2013) | 1 line
SLPVectorizer: Fix whitespace errors
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195221 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
------------------------------------------------------------------------
r195152 | jacksprat | 2013-11-19 12:53:28 -0800 (Tue, 19 Nov 2013) | 1 line
reverts 195057 per request
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195220 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
------------------------------------------------------------------------
r195138 | atrick | 2013-11-19 10:29:45 -0800 (Tue, 19 Nov 2013) | 3 lines
Obvious pasto survived a couple rounds of cleanup.
Caught by Aaron Ballman.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195219 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
------------------------------------------------------------------------
r195129 | mcinally | 2013-11-19 06:36:00 -0800 (Tue, 19 Nov 2013) | 2 lines
Fix assembly operands for the SSE2 cvtsd2ss instruction.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195218 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
------------------------------------------------------------------------
r195118 | chandlerc | 2013-11-19 01:03:18 -0800 (Tue, 19 Nov 2013) | 22 lines
Fix an issue where SROA computed different results based on the relative
order of slices of the alloca which have exactly the same size and other
properties. This was found by a perniciously unstable sort
implementation used to flush out buggy uses of the algorithm.
The fundamental idea is that findCommonType should return the best
common type it can find across all of the slices in the range. There
were two bugs here previously:
1) We would accept an integer type smaller than a byte-width multiple,
and if there were different bit-width integer types, we would accept
the first one. This caused an actual failure in the testcase updated
here when the sort order changed.
2) If we found a bad combination of types or a non-load, non-store use
before an integer typed load or store we would bail, but if we found
the integere typed load or store, we would use it. The correct
behavior is to always use an integer typed operation which covers the
partition if one exists.
While a clever debugging sort algorithm found problem #1 in our existing
test cases, I have no useful test case ideas for #2. I spotted in by
inspection when looking at this code.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195217 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
------------------------------------------------------------------------
r195103 | atrick | 2013-11-18 21:05:43 -0800 (Mon, 18 Nov 2013) | 1 line
Fix patchpoint comments.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195115 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
------------------------------------------------------------------------
r195094 | atrick | 2013-11-18 19:29:59 -0800 (Mon, 18 Nov 2013) | 3 lines
Use symbolic operands in the patchpoint folding routine and fix a spilling bug.
Fixes <rdar://15487687> [JS] AnyRegCC argument ends up being spilled
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195113 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
------------------------------------------------------------------------
r195093 | atrick | 2013-11-18 19:29:56 -0800 (Mon, 18 Nov 2013) | 4 lines
Add an abstraction to handle patchpoint operands.
Hard-coded operand indices were scattered throughout lowering stages
and layers. It was super bug prone.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@195112 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195078 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195077 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195076 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195075 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195074 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | | |
integer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195072 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195071 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
No true functional changes.
Change the "hack" name of emitMipsHackSTOCG to emitSymSTO.
Remove demonstration code in AsmParser for emitMipsHackSTOCG and
emitMipsHackELFFlags. The STO field is in an ELF symbol and is not
an explicit directive. That said, we are missing the compliment call
in AsmParser and that will need to be addressed soon.
XFAIL dummy tests for emitMipsHackELFFlags and emitMipsHackELFFlags.
These will built out with following patches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195067 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195064 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195060 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195059 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
No functionality changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195057 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | | |
types, and make DIType(MDNode*) explicit like all the other DI* node ctors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195055 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit r190888, to fix PR17967. The original change wasn't
the right way to get @feat.00 into the object file. The right fix is to
make @feat.00 be a global symbol.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195053 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
lowering only for load/stores to scalar allocas. The resulting values
confuse the backend and don't add anything because we can describe
array-allocas with a dbg.declare intrinsic just fine.
rdar://problem/15464571
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195052 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
(except functions marked always_inline).
Functions with 'optnone' must also have 'noinline' so they don't get
inlined into any other function.
Based on work by Andrea Di Biagio.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195046 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Moving into a VSrc doesn't always work, since it could be
replaced with an SGPR later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195042 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
No other SGPR operands are allowed, so if VCC is
used, move the other to a VGPR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195041 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Test doesn't actually check the output. I need
to fix add i64 being matched for the addressing
calculations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195040 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195039 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195038 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | | |
The carry always goes to SCC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195037 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195036 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195035 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195034 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When replacing scalar operations with vector,
the wrong implicit output register was used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195033 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195031 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The ifPatternMatch() function was not correctly reporting the number
of matches in some cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195030 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | | |
This is useful when writing test cases for the AMDIL structurizer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195029 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
llc converts all values passed to -mattr= to lowercase, so this
enables us to toggle this feature when using llc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195028 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195026 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195025 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | | |
no guarantee that the buffer will be non-null.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195019 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | | |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195018 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes http://llvm.org/PR16221, http://llvm.org/PR15927
Phabricator: http://llvm-reviews.chandlerc.com/D1236
Patch by Andrew Tulloch!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195016 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | | |
use-after-return are combined.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195014 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In some case the loop exit count computation can overflow. Extend the type to
prevent most of those cases.
The problem is loops like:
int main ()
{
int a = 1;
char b = 0;
lbl:
a &= 4;
b--;
if (b) goto lbl;
return a;
}
The backedge count is 255. The induction variable type is i8. If we add one to
255 to get the exit count we overflow to zero.
To work around this issue we extend the type of the induction variable to i32 in
the case of i8 and i16.
PR17532
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195008 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
for (ConstantFP 0.0)
Fixed an inappropriate use of BuildPairF64 when compiling for MIPS32 with FP64
which resulted in an impossible constraint on the register allocation. It now
uses BuildPairF64_64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195007 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Note that there's no hardware yet that relies on that encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195006 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
encoded.
The immediate field should be encoded as "imm - 1" as the CPU always adds one to that field.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195004 91177308-0d34-0410-b5e6-96231b3b80d8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194997 91177308-0d34-0410-b5e6-96231b3b80d8
|