| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes the way we get fake stack from ASan runtime
(to find use-after-return errors) and the way we represent local
variables:
- __asan_stack_malloc function now returns pointer to newly allocated
fake stack frame, or NULL if frame cannot be allocated. It doesn't
take pointer to real stack as an input argument, it is calculated
inside the runtime.
- __asan_stack_free function doesn't take pointer to real stack as
an input argument. Now this function is never called if fake stack
frame wasn't allocated.
- __asan_init version is bumped to reflect changes in the ABI.
- new flag "-asan-stack-dynamic-alloca" allows to store all the
function local variables in a dynamic alloca, instead of the static
one. It reduces the stack space usage in use-after-return mode
(dynamic alloca will not be called if the local variables are stored
in a fake stack), and improves the debug info quality for local
variables (they will not be described relatively to %rbp/%rsp, which
are assumed to be clobbered by function calls). This flag is turned
off by default for now, but I plan to turn it on after more
testing.
llvm-svn: 224062
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since `MachineInstr` is required to have a trivial destructor, it cannot
remove itself from `LeakDetection`. Remove the calls.
As it happens, this requirement is because `MachineFunction` allocates
all `MachineInstr`s in a custom allocator; when the `MachineFunction` is
destroyed they're dropped of the edge. There's no benefit to detecting
leaks.
llvm-svn: 224061
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives us better leak detection messages, like `Value` has.
This also has the side effect of papering over a problem where
`MachineInstr`s are added as garbage to the leak detector and then
deleted without being removed. If `MDNode::getTemporary()` allocates an
`MDNodeFwdDecl` in the same spot, the leak detector asserts. By
separating `MDNode`s into their own container we lose that assertion.
Since `MachineInstr` is required to have a trivial destructor, its usage
of `LeakDetector` at all is pretty suspect. I'll be sending a patch
soon to strip that out.
llvm-svn: 224060
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously print+verify passes were added in a very unsystematic way, which is
annoying when debugging as you miss intermediate steps and allows bugs to stay
unnotice when no verification is performed.
To make this change practical I added the possibility to explicitely disable
verification. I used this option on all places where no verification was
performed previously (because alot of places actually don't pass the
MachineVerifier).
In the long term these problems should be fixed properly and verification
enabled after each pass. I'll enable some more verification in subsequent
commits.
This is the 2nd attempt at this after realizing that PassManager::add() may
actually delete the pass.
llvm-svn: 224059
|
| |
|
|
| |
llvm-svn: 224056
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches the instruction combiner how to fold a call to 'insertqi' if
the 'length field' (3rd operand) is set to zero, and if the sum between
field 'length' and 'bit index' (4th operand) is bigger than 64.
From the AMD64 Architecture Programmer's Manual:
1. If the sum of the bit index + length field is greater than 64, then the
results are undefined;
2. A value of zero in the field length is defined as a length of 64.
This patch improves the existing combining logic for intrinsic 'insertqi'
adding extra checks to address both point 1. and point 2.
Differential Revision: http://reviews.llvm.org/D6583
llvm-svn: 224054
|
| |
|
|
| |
llvm-svn: 224053
|
| |
|
|
|
|
| |
As a bonus we can actually check the return value.
llvm-svn: 224046
|
| |
|
|
|
|
| |
check-llvm was failing.
llvm-svn: 224045
|
| |
|
|
|
|
|
| |
The static analyzer catches a few potential bugs in LLVMSupport. Add
in asserts to silence the warnings.
llvm-svn: 224044
|
| |
|
|
| |
llvm-svn: 224043
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously print+verify passes were added in a very unsystematic way, which is
annoying when debugging as you miss intermediate steps and allows bugs to stay
unnotice when no verification is performed.
To make this change practical I added the possibility to explicitely disable
verification. I used this option on all places where no verification was
performed previously (because alot of places actually don't pass the
MachineVerifier).
In the long term these problems should be fixed properly and verification
enabled after each pass. I'll enable some more verification in subsequent
commits.
llvm-svn: 224042
|
| |
|
|
| |
llvm-svn: 224041
|
| |
|
|
| |
llvm-svn: 224036
|
| |
|
|
|
|
|
|
|
|
|
| |
The distinction is mostly useful in the front-end. By the time we get here,
there are very few situations where we actually want different behaviour for
Darwin and IOS (in fact Darwin mostly just exists in a few tests). So this
should reduce any surprising weirdness for anyone using it.
No functional change on anything anyone actually cares about.
llvm-svn: 224035
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PPCISelDAGToDAG contained existing code to lower i32 sdiv by a power-of-2 using
srawi/addze, but did not implement the i64 case. DAGCombine now contains a
callback specifically designed for this purpose (BuildSDIVPow2), and part of
the logic has been moved to an implementation of that callback. Doing this
lowering using BuildSDIVPow2 likely does not matter, compared to handling
everything in PPCISelDAGToDAG, for the positive divisor case, but the negative
divisor case, which generates an additional negation, can potentially benefit
from additional folding from DAGCombine. Now, both the i32 and the i64 cases
have been implemented.
Fixes PR20732.
llvm-svn: 224033
|
| |
|
|
| |
llvm-svn: 224029
|
| |
|
|
| |
llvm-svn: 224028
|
| |
|
|
| |
llvm-svn: 224027
|
| |
|
|
| |
llvm-svn: 224026
|
| |
|
|
|
|
| |
+ intrinsics + tests
llvm-svn: 224019
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5840
llvm-svn: 224017
|
| |
|
|
|
|
|
|
|
|
| |
for llvm.dbg.value.
Patch by Amjad Aboud
Differential Revision: http://reviews.llvm.org/D6525
llvm-svn: 224015
|
| |
|
|
|
|
|
|
| |
actual immediate
This should fix PR21878.
llvm-svn: 224010
|
| |
|
|
|
|
|
|
|
|
| |
Properly determine whether or not a phi was added by splitting.
Check against the current VNInfo of OrigLI instead of against the
OrigVNI argument.
Patch provided by Jonas Paulsson. Reviewed by Quentin Colombet.
llvm-svn: 224009
|
| |
|
|
| |
llvm-svn: 224008
|
| |
|
|
| |
llvm-svn: 224007
|
| |
|
|
|
|
| |
Extract the creation of overflow result tuples in a separate function. NFC.
llvm-svn: 224006
|
| |
|
|
| |
llvm-svn: 224005
|
| |
|
|
|
|
|
|
| |
(incorrect-variable-debugloc1.ll) failed for llvm-ppc64.
The test is failing for llvm-ppc64 because for this platform the location list is not being generated at all (most likely because of the bug in PPC code optimization or generation). I will file a bug agains PPC compiler, but meanwhile, until PPC bug is fixed, I will have to revert my change.
llvm-svn: 224000
|
| |
|
|
| |
llvm-svn: 223998
|
| |
|
|
|
|
|
|
| |
ownership and deletion of the values.
Ideally we would store the MultiClasses by value directly in the maps, but I had some trouble with that before and this at least fixes the leak.
llvm-svn: 223997
|
| |
|
|
|
|
|
|
|
| |
We can't reach those from zext, but other parts of the backend (the shuffle
lowering) generate 256-bit VZEXT nodes.
Fixes PR21876.
llvm-svn: 223996
|
| |
|
|
|
|
| |
PR21799!
llvm-svn: 223995
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change moves the ownership and access of GCFunctionInfo (the object which describes the safepoints associated with a safepoint under GCRoot) to GCModuleInfo. Previously, this was owned by GCStrategy which was in turned owned by GCModuleInfo. This made GCStrategy module specific which is 'surprising' given it's name and other purposes.
There's a few more changes needed, but we're getting towards the point we can reuse GCStrategy for gc.statepoint as well.
p.s. The style of this code ends up being a mess. I was trying to move code around without otherwise changing much. Once I get the ownership structure rearranged, I will go through and fixup spacing, naming, comments etc.
Differential Revision: http://reviews.llvm.org/D6587
llvm-svn: 223994
|
| |
|
|
| |
llvm-svn: 223991
|
| |
|
|
|
|
|
|
| |
Quite a major error here: the expansions for the Pseudos with and without
folded load were mixed up. Fortunately it only affects ARM-mode, when not using
movw/movt, on Darwin. I'm guessing no-one actually uses that combination.
llvm-svn: 223986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
DW_OP_const <const> doesn't describe a constant value, but a value at a constant address.
The proper way to describe a constant value is DW_OP_constu <const>, DW_OP_stack_value.
Added DW_OP_stack_value to the stack.
-This line, and those below, will be ignored--
M lib/CodeGen/AsmPrinter/DwarfDebug.cpp
A test/DebugInfo/incorrect-variable-debugloc1.ll
llvm-svn: 223981
|
| |
|
|
| |
llvm-svn: 223978
|
| |
|
|
|
|
| |
This divide can produce incorrect results as we are using an unsigned divide for what should be a modular divide. This change reverts back to a more conservative computation using trailing zeros.
llvm-svn: 223974
|
| |
|
|
| |
llvm-svn: 223971
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 223970
|
| |
|
|
|
|
| |
Zero is usually a nicer constant to have than -1.
llvm-svn: 223969
|
| |
|
|
|
|
|
| |
X shifted by undef results in undef because the undef value can
represent values greater than the width of the operands.
llvm-svn: 223968
|
| |
|
|
| |
llvm-svn: 223967
|
| |
|
|
|
|
|
|
| |
These methods are only used by MCJIT and are very specific to it. In fact, they
are also fairly specific to the fact that we have a dynamic linker of
relocatable objects.
llvm-svn: 223964
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the large code model we have to first get the address of the GOT entry, load
the address of the constant, and then load the constant itself.
To avoid these loads and the GOT entry alltogether this commit changes the way
how FP constants are materialized in the large code model. The constats are now
materialized in a GPR and then bitconverted/moved into the FPR.
Reviewed by Tim Northover
Fixes rdar://problem/16572564.
llvm-svn: 223941
|
| |
|
|
| |
llvm-svn: 223940
|
| |
|
|
| |
llvm-svn: 223933
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add patterns to match SSE (shufpd) and AVX (vpermilpd) shuffle codegen
when storing the high element of a v2f64. The existing patterns were
only checking for an unpckh type of shuffle.
http://llvm.org/bugs/show_bug.cgi?id=21791
Differential Revision: http://reviews.llvm.org/D6586
llvm-svn: 223929
|