| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 216798
|
| |
|
|
|
|
| |
enum values
llvm-svn: 216797
|
| |
|
|
| |
llvm-svn: 216796
|
| |
|
|
|
|
|
| |
This adds the printing of the LC_SEGMENT load command and sections,
LC_SYMTAB and LC_DYSYMTAB load commands.
llvm-svn: 216795
|
| |
|
|
| |
llvm-svn: 216794
|
| |
|
|
| |
llvm-svn: 216793
|
| |
|
|
|
|
|
|
|
|
| |
Rushed when I realized I hadn't committed the FreeDeleter for a clang
change I'd committed, and didn't check that I had things lying around in
my client.
Apologies for the noise.
llvm-svn: 216792
|
| |
|
|
| |
llvm-svn: 216791
|
| |
|
|
|
|
| |
be freed rather than deleted.
llvm-svn: 216790
|
| |
|
|
| |
llvm-svn: 216789
|
| |
|
|
| |
llvm-svn: 216788
|
| |
|
|
| |
llvm-svn: 216787
|
| |
|
|
| |
llvm-svn: 216786
|
| |
|
|
|
|
|
|
|
| |
A couple of these arguments were passed by void* as a rather extreme
example of pimpling. Adjusting this to a more classic form of the idiom
(involving forward declarations) makes this more legible and allows
explicit passing of ownership via std::unique_ptr.
llvm-svn: 216785
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Just fixing comments, no functional change.
Test Plan: N/A
Reviewers: jfb
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D5130
llvm-svn: 216784
|
| |
|
|
| |
llvm-svn: 216783
|
| |
|
|
|
|
|
|
|
| |
This avoids encoding information about the function prototype into the
thunk at the cost of some function prototype bitcast gymnastics.
Fixes PR20653.
llvm-svn: 216782
|
| |
|
|
| |
llvm-svn: 216781
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If a variadic function body contains a musttail call, then we copy all
of the remaining register parameters into virtual registers in the
function prologue. We track the virtual registers through the function
body, and add them as additional registers to pass to the call. Because
this is all done in virtual registers, the register allocator usually
gives us good code. If the function does a call, however, it will have
to spill and reload all argument registers (ew).
Forwarding regparms on x86_32 is not implemented because most compilers
don't support varargs in 32-bit with regparms.
Reviewers: majnemer
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5060
llvm-svn: 216780
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've rejected these kinds of functions since r28405 in 2006 because
it's impossible to lower the return of a callee cleanup varargs
function. However there are lots of legal ways to leave such a function
without returning, such as aborting. Today we can leave a function with
a musttail call to another function with the correct prototype, and
everything works out.
I'm removing the verifier check declaring that a normal return from such
a function is UB.
Reviewed By: nlewycky
Differential Revision: http://reviews.llvm.org/D5059
llvm-svn: 216779
|
| |
|
|
|
|
| |
clause causes clang to crash.
llvm-svn: 216778
|
| |
|
|
| |
llvm-svn: 216777
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
values
This patch checks for DAG patterns that are an add or a sub followed by a
compare on 16 and 8 bit inputs. Since AArch64 does not support those types
natively they are legalized into 32 bit values, which means that mask operations
are inserted into the DAG to emulate overflow behaviour. In many cases those
masks do not change the result of the processing and just introduce a dependent
operation, often in the middle of a hot loop.
This patch detects the relevent DAG patterns and then tests to see if the
transforms are equivalent with and without the mask, removing the mask if
possible. The exact mechanism of this patch was discusses in
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074444.html
There is a reasonably good chance there are missed oppurtunities due to similiar
(but not identical) DAG patterns that could be funneled into this test, adding
them should be simple if we see test cases.
Tests included.
rdar://13754426
llvm-svn: 216776
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new solution is to not use this lowering if there are any dynamic
allocas in the current function. We know up front if there are dynamic
allocas, but we don't know if we'll need to create stack temporaries
with large alignment during lowering. Conservatively assume that we will
need such temporaries.
Reviewed By: hans
Differential Revision: http://reviews.llvm.org/D5128
llvm-svn: 216775
|
| |
|
|
| |
llvm-svn: 216774
|
| |
|
|
| |
llvm-svn: 216773
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I hope this is the last fix for x64 relocations as I've wasted
a few days on this.
This caused a mysterious issue that some C++ programs crash on
startup. It was because a null pointer is passed as argv to main.
__tmainCRTStartup calls main, but before that it calls all
initialization routines between .text$xc_a and .text$xc_z.
pre_cpp_init is one of such routines, and it is the one who
initializes a heap pointer for argv for later use. That routine
was not called for some reason.
It turned out that __tmainCRTStartup was skipping a block of
code because of the relocation bug. A condition in the function
depends on a memory load, and that memory load was referring
a wrong location. As a result a jump instruction took the
wrong branch, skipping pre_cpp_init and so on.
This patch fixes the issue. Also added more tests to fix them
once and for all.
llvm-svn: 216772
|
| |
|
|
|
|
|
|
| |
Even loads/stores that have a stronger ordering than monotonic can be safe.
The rule is no release-acquire pair on the path from the QueryInst, assuming that
the QueryInst is not atomic itself.
llvm-svn: 216771
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
llgs Linux is no longer doing the translation to some gdb fixed signal
numbers. This change modifies the test method to take in the signo
expected for a segfault. The debugserver test uses the fixed gdb number,
and everything else uses signal.SIGSEGV for the platform.
Sidenote: I somehow did not see this reported in multicore tests.
I will need to verify that we aren't missing test failures in that
script. I need to verify why this wasn't more obvious with
test/dosep.py.
llvm-svn: 216770
|
| |
|
|
|
|
|
|
| |
in the super class, do not issue the warning about property
in current class's protocol will not be auto synthesized.
// rdar://18179833
llvm-svn: 216769
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Mostly renaming the (not very explicit) variables Tmp0, .. Tmp4, and grouping
related statements together, along with a few lines of comments for the
surprising parts.
No functional change intended.
Test Plan: make check-all
Reviewers: jfb
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5088
llvm-svn: 216768
|
| |
|
|
| |
llvm-svn: 216767
|
| |
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D4430 for more details.
Change by Paul Osmialowski.
llvm-svn: 216766
|
| |
|
|
| |
llvm-svn: 216765
|
| |
|
|
|
|
|
| |
FoldingSet, another intrusive data structure that could use some
unique_ptr love on its interfaces. Eventually.
llvm-svn: 216764
|
| |
|
|
|
|
|
|
|
|
|
|
| |
People have been incorrectly using "-analyzer-disable-checker" to
silence analyzer warnings on a file, when analyzing a project. Add
the "-analyzer-disable-all-checks" option, which would allow the
suppression and suggest it as part of the error message for
"-analyzer-disable-checker". The idea here is to compose this with
"--analyze" so that users can selectively opt out specific files from
static analysis.
llvm-svn: 216763
|
| |
|
|
|
|
|
|
| |
I suspect llvm::ilist should take elements by unique_ptr, since it does
take ownership of the element (by stitching it into the linked list) -
one day.
llvm-svn: 216761
|
| |
|
|
| |
llvm-svn: 216759
|
| |
|
|
| |
llvm-svn: 216758
|
| |
|
|
|
|
| |
Followup to r215086.
llvm-svn: 216757
|
| |
|
|
| |
llvm-svn: 216756
|
| |
|
|
| |
llvm-svn: 216755
|
| |
|
|
| |
llvm-svn: 216754
|
| |
|
|
|
|
|
|
|
|
|
| |
Do not warn when property declared in class's protocol will be auto-synthesized
by its uper class implementation because super class has also declared this
property while this class has not. Continue to warn if current class
has declared the property also (because this declaration will not result
in a 2nd synthesis).
rdar://18152478
llvm-svn: 216753
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Again, if shared ownership is the right model here (I assume it is,
given graph algorithms & such) this could be tidied up (the 'release'
call removed in favor of something safer) by having
IntrunsiveRefCntPointer constructible from a unique_ptr.
(& honestly I'd probably favor taking a page out of shared_ptr's book,
allowing implicit construction from a unique_ptr rvalue, and only allow
explicit from a raw pointer - currently IntrusiveRefCntPointer can
implicitly own from a raw pointer, which seems unsafe)
llvm-svn: 216752
|
| |
|
|
| |
llvm-svn: 216751
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we select a trunc instruction we don't emit any code if the type is already
i32 or smaller. This is because the instruction that uses the truncated value
will deal with it.
This behavior can incorrectly transfer a kill flag, which was meant for the
result of the truncate, onto the source register.
%2 = trunc i32 %1 to i16
... = ... %2 -> ... = ... vreg1 <kill>
... = ... %1 ... = ... vreg1
This commit fixes this by emitting a COPY instruction, so that the result and
source register are distinct virtual registers.
This fixes rdar://problem/18178188.
llvm-svn: 216750
|
| |
|
|
| |
llvm-svn: 216749
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D5108 for details.
This change does the following:
* eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter.
* replaces the Process UnixSignals storage with a shared pointer.
* adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used.
* adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant.
* replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process.
This change also enables some future patches that will enable llgs to be used for local Linux debugging.
llvm-svn: 216748
|
| |
|
|
|
|
|
|
| |
at a time.
<rdar://problem/13314462>
llvm-svn: 216747
|