| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Note: There are no uses of these functions outside of
SimplifyLibCalls, so they could be static functions in
that file.
llvm-svn: 258172
|
|
|
|
|
|
|
| |
Newly-built Clangs don't automatically find the SDK, and newer versions
of Mac OS X don't provide it under /usr/include etc.
llvm-svn: 258169
|
|
|
|
|
|
| |
This didn't work for 3.7, but hopefully it should work now.
llvm-svn: 258168
|
|
|
|
| |
llvm-svn: 258167
|
|
|
|
| |
llvm-svn: 258166
|
|
|
|
|
|
| |
Patch by Arpith Jacob. Thanks!
llvm-svn: 258165
|
|
|
|
| |
llvm-svn: 258164
|
|
|
|
| |
llvm-svn: 258163
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16297
llvm-svn: 258161
|
|
|
|
|
|
|
|
|
|
| |
Image info flags describe the objc constraint which is GC/retain/release/etc.
These need to be parsed and stored in the file so that we can do error checking.
That will come in a later commit.
llvm-svn: 258160
|
|
|
|
|
|
| |
According the build bots, clang is using the Registry class somewhere as well. Will reapply with appropriate clang changes at a later point.
llvm-svn: 258159
|
|
|
|
|
|
|
| |
This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
llvm-svn: 258158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Registry class constructs a linked list of nodes whose storage is inside static variables and nodes are added via static initializers. The trick is that those static initializers are in both the LLVM code base, and some random plugin that might get loaded in at runtime. The existing code tries to use C++ templates and their ODR rules to get a single definition of the registry for each type, but, experimentally, this doesn't quite work as designed. (Well, the entire structure doesn't. It might not actually be an ODR problem.)
Previously, when I tried moving the GCStrategy class (along with it's registry) from CodeGen to IR, I ran into a problem where asking the GCStrategyRegistry a question would return inconsistent results depending on whether you asked from CodeGen (where the static initializers still were) or Transforms. My best guess is that this is a result of either a) an order of initialization error, or b) we ended up with two copies of the registry being created. I remember at the time having convinced myself it was probably (b), but I don't have any of my notes around from that investigation any more.
See http://reviews.llvm.org/rL226311 for the original patch in question.
This patch tries to remove the possibility of (b) above. (a) was already fixed in change 258109.
Differential Revision: http://reviews.llvm.org/D16170
llvm-svn: 258157
|
|
|
|
|
|
|
|
|
|
| |
This patch creates the profile data variable before lowering the profile intrinsics.
Reviewers: davidxl, silvas
Differential Revision: http://reviews.llvm.org/D16015
llvm-svn: 258156
|
|
|
|
|
|
|
|
| |
Our loop construct is not a way to identify cycles in the CFG. This wasn't immediately obvious from the header, so clarify that fact.
The motivation for this was that I just fixed a out of tree bug due to a mistaken assumption (on my part) on what a Loop actually was. While it was fresh in my mind, I wanted to document the key point.
llvm-svn: 258154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pow(x, [small integer]) calls
This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
As with D15937, the intent of the patch is to preserve the current behavior of the transform
except that we use the pow call's 'fast' attribute as a trigger rather than a function-level
attribute.
The TODO comment notes a potential follow-on patch that would propagate FMF to the new
instructions.
Differential Revision: http://reviews.llvm.org/D16122
llvm-svn: 258153
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
until we are visiting their declcontext.
This fixes a regression introduced in r256962:
When building debug info for a typdef'd anonymous tag type, we would be
visiting the inner anonymous type first thus creating a "typedef changes
linkage of anonymous type, but linkage was already computed" error.
rdar://problem/24199640
llvm-svn: 258152
|
|
|
|
|
|
| |
Changed whitespace so comments line up.
llvm-svn: 258151
|
|
|
|
|
|
|
|
|
|
| |
its clients can easily dump it out for informational messages.
http://reviews.llvm.org/D16244
Submitting on behalf of vishwesh@google.com.
llvm-svn: 258150
|
|
|
|
|
|
|
| |
This brings the pr26208 testcase down to 3.2 seconds. Not checking it in
since it does create a 4GB .o file.
llvm-svn: 258149
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
add_version_info_from_vcs was setting SVN_REVISION to the last fetched
svn revision when using git svn instead of the svn revision
corresponding to HEAD. This leads to conflicts with the definition of
SVN_REVISION in SVNVersion.inc generated by GetSVN.cmake when HEAD is
not the most recently fetched svn revision.
Use 'git svn info' to determine SVN_REVISION when git svn is being used
instead (as is done in GetSVN.cmake).
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16299
llvm-svn: 258148
|
|
|
|
| |
llvm-svn: 258147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
get{Source,Result}ElementType.
Summary:
GEPOperator: provide getResultElementType alongside getSourceElementType.
This is made possible by adding a result element type field to GetElementPtrConstantExpr, which GetElementPtrInst already has.
GEP: replace get(Pointer)ElementType uses with get{Source,Result}ElementType.
Reviewers: mjacob, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16275
llvm-svn: 258145
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16294
llvm-svn: 258144
|
|
|
|
|
|
| |
Only set -DSVN_REVISION if CLANG_APPEND_VC_REV=On
llvm-svn: 258143
|
|
|
|
|
|
|
|
|
| |
Teach the register stackifier to rematerialize constants that have multiple
uses instead of leaving them in registers. In the WebAssembly encoding, it's
the same code size to materialize most constants as it is to read a value
from a register.
llvm-svn: 258142
|
|
|
|
|
|
|
|
|
| |
The value size was always 1 or 0, so we don't need to store it.
In a no asserts build this takes the testcase of pr26208 from 11 to 10
seconds.
llvm-svn: 258141
|
|
|
|
| |
llvm-svn: 258140
|
|
|
|
| |
llvm-svn: 258139
|
|
|
|
|
|
| |
are resolved.
llvm-svn: 258138
|
|
|
|
| |
llvm-svn: 258137
|
|
|
|
|
|
|
|
| |
According to x86 spec "xlat m8" is a legal instruction and it is equivalent to "xlatb".
Differential Revision: http://reviews.llvm.org/D15150
llvm-svn: 258135
|
|
|
|
|
|
|
|
|
|
|
|
| |
argument.
Reviewers: eddyb
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16321
llvm-svn: 258134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes shebang lines in Python script files.
Most Python scripts in LLVM & Clang are using this shebang line.
[[ https://mail.python.org/pipermail/tutor/2007-June/054816.html | Here]] is an explanaiton of why such line should be used instead of what is currently in these few files.
Reviewers: klimek, alexfh
Subscribers: cfe-commits
Patch by Kirill Bobyrev!
Differential Revision: http://reviews.llvm.org/D16270
llvm-svn: 258133
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following are legal according to X86 spec:
ins mem, DX
outs DX, mem
lods mem
stos mem
scas mem
cmps mem, mem
movs mem, mem
Differential Revision: http://reviews.llvm.org/D14827
llvm-svn: 258132
|
|
|
|
| |
llvm-svn: 258131
|
|
|
|
| |
llvm-svn: 258130
|
|
|
|
|
|
|
|
|
| |
No tests since llvm-mc takes 14 seconds on it. I will try to improve it
and then test.
Part of pr26208.
llvm-svn: 258129
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[cpp.cond]p4:
Prior to evaluation, macro invocations in the list of preprocessing
tokens that will become the controlling constant expression are replaced
(except for those macro names modified by the 'defined' unary operator),
just as in normal text. If the token 'defined' is generated as a result
of this replacement process or use of the 'defined' unary operator does
not match one of the two specified forms prior to macro replacement, the
behavior is undefined.
This isn't an idle threat, consider this program:
#define FOO
#define BAR defined(FOO)
#if BAR
...
#else
...
#endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch. Emit a warning about this undefined behavior.
One problem is that this also applies to function-like macros. While the
example above can be written like
#if defined(FOO) && defined(BAR)
#defined HAVE_FOO 1
#else
#define HAVE_FOO 0
#endif
there is no easy way to rewrite a function-like macro like `#define FOO(x)
(defined __foo_##x && __foo_##x)`. Function-like macros like this are used in
practice, and compilers seem to not have differing behavior in that case. So
this a default-on warning only for object-like macros. For function-like
macros, it is an extension warning that only shows up with `-pedantic`.
(But it's undefined behavior in both cases.)
llvm-svn: 258128
|
|
|
|
| |
llvm-svn: 258127
|
|
|
|
| |
llvm-svn: 258126
|
|
|
|
| |
llvm-svn: 258125
|
|
|
|
|
|
|
|
| |
cover all width and types (pd/ps/sd/ss) of fixupimm instruction and inrtinsics
Differential Revision: http://reviews.llvm.org/D16313
llvm-svn: 258124
|
|
|
|
|
|
|
|
|
|
| |
Before:
a[ ::b::c];
After:
a[::b::c];
llvm-svn: 258123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The issue arises because LLDB is not
able to read the vdso library correctly.
The fix adds memory allocation callbacks
to allocate sufficient memory in case the
requested offsets don't fit in the memory
buffer allocated for the ELF.
Reviewers: lldb-commits, clayborg, deepak2427, ovyalov, labath, tberghammer
Differential Revision: http://reviews.llvm.org/D16107
llvm-svn: 258122
|
|
|
|
|
|
|
|
| |
Removal of the interceptor broke libtsan interface in gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68824
Add back a simple interceptor.
llvm-svn: 258119
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
R_386_GOT32 has multiple descriptions:
"System V Application Binary Interface Intel386 Architecture Processor Supplement Version 1.1" (https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-1.1.pdf), p36 contains next calculation for R_386_GOT32: G + A - GOT.
SYSTEM V APPLICATION BINARY INTERFACE 4 (https://refspecs.linuxfoundation.org/elf/abi386-4.pdf, p78) tolds us its G + A - P.
Oracle docs (https://docs.oracle.com/cd/E19455-01/816-0559/chapter6-26/index.html) says its should be G + A.
gold/bfd calculates it as "G + A - GOT", but GOT means the end of the GOT section.
Patch fixes current calculation to gold/ld behavior.
Differential revision: http://reviews.llvm.org/D15750
llvm-svn: 258115
|
|
|
|
|
|
|
|
| |
TestHelloWorld seems to be passing now as far as I can tell. TestExitDuringStep is still hanging.
I have marked the relevant tests as flaky, which should handle the timeouts now as well. I'll be
monitoring the buildbots for fallout.
llvm-svn: 258114
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ELF symbol table always contain the size of the symbols so we
don't have to try to guess them based on the address of the next
symbol (it is needed for mach-o).
The change fixes an issue when a symbol is removed after a 0 size
symbol (e.g. because the second one is not public) what previously
caused the symbol lookup algorithm to end up with showing the 0 size
symbol even for the later addresses (what are not part of any symbol).
That symbol lookup error can confuse the user and also confuses the
current stack unwinder.
Re-commit this CL after fixing the issue with gcc-4.9.2 on i386 Linux.
Differential revision: http://reviews.llvm.org/D16186
llvm-svn: 258113
|
|
|
|
|
|
|
|
|
| |
Rewording/expansion of CMake options
suggested by Dan Liew.
See http://reviews.llvm.org/D16208.
llvm-svn: 258112
|