| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 201681
|
| |
|
|
|
|
|
|
|
| |
According to http://gcc.gnu.org/projects/cxx0x.html,
override and final keyword was added in gcc 4.7. Thus,
we should not use these keywords in gcc 4.6 even when
__GXX_EXPERIMENTAL_CXX0X__ is available.
llvm-svn: 201679
|
| |
|
|
|
|
|
| |
This causes the LLVMgold plugin to segfault. More information on the
replies to r201608.
llvm-svn: 201669
|
| |
|
|
|
|
|
| |
If LLVM is built without X86 as a supported target then the test would
mysteriously fail.
llvm-svn: 201668
|
| |
|
|
|
|
|
| |
Just a wild stab in the dark really, but in the absence of any ability to
reproduce the problem...
llvm-svn: 201658
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On x86, shifting a vector by a scalar is significantly cheaper than shifting a
vector by another fully general vector. Unfortunately, because SelectionDAG
operates on just one basic block at a time, the shufflevector instruction that
reveals whether the right-hand side of a shift *is* really a scalar is often
not visible to CodeGen when it's needed.
This adds another handler to CodeGenPrepare, to sink any useful shufflevector
instructions down to the basic block where they're used, predicated on a target
hook (since on other architectures, doing so will often just introduce extra
real work).
rdar://problem/16063505
llvm-svn: 201655
|
| |
|
|
|
|
| |
This change also removes CMAKE_LINK_FLAGS setting that seems to be ignored by cmake.
llvm-svn: 201654
|
| |
|
|
| |
llvm-svn: 201651
|
| |
|
|
|
|
| |
handle all the FP operations. This increases format by 1 bit, but decreases opcode map by 1 bit so the TSFlags size doesn't change.
llvm-svn: 201649
|
| |
|
|
| |
llvm-svn: 201646
|
| |
|
|
| |
llvm-svn: 201645
|
| |
|
|
|
|
| |
0xa6/0xa7, and adding MRM_C0/MRM_E0 forms. Removes 376K from the disassembler tables.
llvm-svn: 201641
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Load Configuration Table may contain a pointer to SEH table. This patch is to
print the offset to the table. Printing SEH table contents is a TODO.
The layout of Layout Configuration Table is described in Microsoft PE/COFF
Object File Format Spec, but the table's offset/size descriptions seems to be
totally wrong, at least in revision 8.3 of the spec. I believe the table in
this patch is the correct one.
llvm-svn: 201638
|
| |
|
|
| |
llvm-svn: 201633
|
| |
|
|
|
|
|
|
|
|
|
| |
This enhances the macro parser to parse and handle parameter qualifications,
which is needed to support required formal parameters in macro definitions. A
required parameter may not be defaulted (though providing a default value is
accepted with a warning). This improves GAS compatibility.
Partially addresses PR9248.
llvm-svn: 201630
|
| |
|
|
|
|
|
|
|
|
| |
Rather than using std::pair, create a structure to represent the type. This is
a preliminary refactoring to enable required parameter handling. Additional
state is needed to indicate required parameters. This has a minor side effect
of improving readability by providing more accurate names compared to first and
second.
llvm-svn: 201629
|
| |
|
|
| |
llvm-svn: 201625
|
| |
|
|
|
|
|
| |
Now that llvm's codegen knows to use an 'l' prefix when needed, we can just
use PrivateLinkage.
llvm-svn: 201624
|
| |
|
|
|
|
|
|
|
|
| |
When outputting an object we check its section to find its name, but when
looking for the section with -ffunction-section we look for the symbol name.
Break the loop by requesting a name with the private prefix when constructing
the section name. This matches the behavior before r201608.
llvm-svn: 201622
|
| |
|
|
|
|
|
|
|
|
| |
Some references to llvm-gcc were so crusty that I wasn't sure how to
proceed and so I've left them intact.
I also slipped in a quick peephole fix to use a :doc: link instead of
raw HTML link.
llvm-svn: 201619
|
| |
|
|
|
|
|
| |
From a cursory look it seems like all the described commandline options
and such apply to clang just fine, but I'd appreciate a second opinion.
llvm-svn: 201616
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The IR
@foo = private constant i32 42
is valid, but before this patch we would produce an invalid MachO from it. It
was invalid because it would use an L label in a section where the liker needs
the labels in order to atomize it.
One way of fixing it would be to just reject this IR in the backend, but that
would not be very front end friendly.
What this patch does is use an 'l' prefix in sections that we know the linker
requires symbols for atomizing them. This allows frontends to just use
private and not worry about which sections they go to or how the linker handles
them.
One small issue with this strategy is that now a symbol name depends on the
section, which is not available before codegen. This is not a problem in
practice. The reason is that it only happens with private linkage, which will
be ignored by the non codegen users (llvm-nm and llvm-ar).
llvm-svn: 201608
|
| |
|
|
|
|
| |
This is quiet a bit less confusing now that TargetData was renamed DataLayout.
llvm-svn: 201606
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
findOrEmitSection).
Vaidas Gasiunas's patch, r201259, fixed one instance where we were always
allocating sections as text. This patch fixes the remaining buggy call sites.
No test case: This isn't breaking anything that I know of, it's just
inconsistent.
<rdar://problem/15943542>
llvm-svn: 201605
|
| |
|
|
| |
llvm-svn: 201601
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes several test failures when building LLVM on a MIPS host.
The failures were:
LLVM :: DebugInfo/enum.ll
LLVM :: DebugInfo/inlined-arguments.ll
LLVM :: DebugInfo/member-order.ll
LLVM :: DebugInfo/namespace.ll
LLVM :: DebugInfo/template-recursive-void.ll
LLVM :: DebugInfo/tu-composite.ll
LLVM :: DebugInfo/two-cus-from-same-file.ll
LLVM :: Linker/type-unique-simple-a.ll
LLVM :: Linker/type-unique-simple2.ll
Reviewers: jacksprat, matheusalmeida
Reviewed By: matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D2721
llvm-svn: 201582
|
| |
|
|
|
|
| |
TargetData was renamed DataLayout back in r165242.
llvm-svn: 201581
|
| |
|
|
| |
llvm-svn: 201573
|
| |
|
|
| |
llvm-svn: 201563
|
| |
|
|
|
|
|
|
|
| |
BuildMI instructions were not including MachineMemOperand information.
This was discovered by 'SingleSource/Benchmarks/Stanford/Oscar' failing
due to a FrameIndex load incorrectly being hoisted by postra-machine-licm.
No other tests have been found to fail.
llvm-svn: 201562
|
| |
|
|
| |
llvm-svn: 201561
|
| |
|
|
|
|
|
|
|
| |
Modifying build_llvm to handle SDKROOT being the name of an SDK rather than a
path. This will still work if SDKROOT is a path.
rdar://problem/15162322
llvm-svn: 201560
|
| |
|
|
|
|
|
| |
It's rather odd to have the flag enabling and disabling this pass only affect a
single target.
llvm-svn: 201559
|
| |
|
|
| |
llvm-svn: 201558
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In gcov, the -o flag can accept either a directory or a file name.
When given a directory, the gcda and gcno files are expected to be in
that directory. When given a file, the gcda and gcno files are
expected to be named based on the stem of that file. Non-existent
paths are treated as files.
This implements compatible behaviour.
llvm-svn: 201555
|
| |
|
|
| |
llvm-svn: 201551
|
| |
|
|
|
|
| |
32-bit mode counterparts for cases where there is also a OpSize16 instruction.
llvm-svn: 201550
|
| |
|
|
| |
llvm-svn: 201546
|
| |
|
|
| |
llvm-svn: 201541
|
| |
|
|
|
|
| |
instruction with 0xf2/f3/66 were in front of them, but don't themselves have a prefix. For now this doesn't change any bbehavior, but plan to use it to fix some bugs in the disassembler.
llvm-svn: 201538
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introducing llvm-profdata, a tool for merging profile data generated by
PGO instrumentation in clang.
- The name indicates a file extension of <name>.profdata. Eventually
profile data output by clang should be changed to that extension.
- llvm-profdata merges two profiles. However, the name is more general,
since it will likely pick up more tasks (such as summarizing a single
profile).
- llvm-profdata parses the current text-based format, but will be
updated once we settle on a binary format.
<rdar://problem/15949645>
llvm-svn: 201535
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ldrd r6, r7 [r2, #15]
simply gives an error and does not triggers an assertion.
As Jim points out, the diagnostic is really strange here,
but fixing that would be more complicated. The missing
comma results in the parser expecting a construct like r2[2],
which is the vector index thing the error message is talking
about. That's not what the user intended, though, and there's
nothing else in the instruction that looks at all like a vector.
Yet more fallout from not having a real parser here and trying
to do context-free generic matching for addressing modes.
rdar://15097243
llvm-svn: 201531
|
| |
|
|
|
|
|
|
|
| |
This is implemented by handling assignments to the '.' pseudo symbol
as ".org" directives.
Differential Revision: http://llvm-reviews.chandlerc.com/D2625
llvm-svn: 201530
|
| |
|
|
|
|
| |
should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860.
llvm-svn: 201507
|
| |
|
|
| |
llvm-svn: 201502
|
| |
|
|
|
|
| |
vectorizeTree()). radar://16064178
llvm-svn: 201501
|
| |
|
|
|
|
|
| |
Add some tests to explicitly validate handling of comma and non-comma separated
arguments.
llvm-svn: 201500
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until this point only macro definition with named parameters were parsed but the
names were ignored. This adds support for using that information for named
parameter instantiation.
In order to support the full semantics of the keyword arguments, the arguments
are no longer lazily initialised since the keyword arguments can be specified
out of order and partially if they are defaulted. Prepopulate the arguments
with the default value for any defaulted parameters, and then parse the
specified arguments.
This simplies some of the handling of the arguments in the inner loop since
empty arguments simply increment the parameter index and move on.
Note that keyword and positional arguments cannot be mixed.
llvm-svn: 201499
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NaCl's ARM ABI uses 16 byte stack alignment, so set that in
ARMSubtarget.cpp.
Using 16 byte alignment exposes an issue in code generation in which a
varargs function leaves a 4 byte gap between the values of r1-r3 saved
to the stack and the following arguments that were passed on the
stack. (Previously, this code only needed to support 4 byte and 8
byte alignment.)
With this issue, llc generated:
varargs_func:
sub sp, sp, #16
push {lr}
sub sp, sp, #12
add r0, sp, #16 // Should be 20
stm r0, {r1, r2, r3}
ldr r0, .LCPI0_0 // Address of va_list
add r1, sp, #16
str r1, [r0]
bl external_func
Fix the bug by checking for "Align > 4". Also simplify the code by
using OffsetToAlignment(), and update comments.
Differential Revision: http://llvm-reviews.chandlerc.com/D2677
llvm-svn: 201497
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During LSR of one loop we can run into a situation where we have to expand the
start of a recurrence of a loop induction variable in this loop. This start
value is a value derived of the induction variable of a preceeding loop. SCEV
has cannonicalized this value to a different recurrence than the recurrence of
the preceeding loop's induction variable (the type and/or step direction) has
changed). When we come to instantiate this SCEV we created a second induction
variable in this preceeding loop. This patch tries to base such derived
induction variables of the preceeding loop's induction variable.
This helps twolf on arm and seems to help scimark2 on x86.
Reapply with a fix for the case of a value derived from a pointer.
radar://15970709
llvm-svn: 201496
|