| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
| 
|  | 
We should be using the llvm namespace and not an anonymous namespace
in a header file.
llvm-svn: 204450
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
entry at a time.
Some targets require more than one relocation entry to perform a relocation.
This change allows processRelocationRef to process more than one relocation
entry at a time by passing the relocation iterator itself instead of just
the relocation entry.
Related to <rdar://problem/16199095>
llvm-svn: 204439
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Extend the target hook to take also the operand index into account when
calculating the cost of the constant materialization.
Related to <rdar://problem/16381500>
llvm-svn: 204435
 | 
| | 
| 
| 
| 
| 
|  | 
Related to <rdar://problem/16381500>
llvm-svn: 204434
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
instructions.
Originally the algorithm would search for expensive constants and track their
users, which could be instructions and constant expressions. This change only
tracks the constants for instructions, but constant expressions are indirectly
covered too. If an operand is an constant expression, then we look through the
expression to find anny expensive constants.
The algorithm keep now track of the instruction and the operand index where the
constant is used. This allows more precise hoisting of constant materialization
code for PHI instructions, because we only hoist to the basic block of the
incoming operand. Before we had to find the idom of all PHI operands and hoist
the materialization code there.
This also makes updating of instructions easier. Before we had to keep track of
the original constant, find it in the instructions, and then replace it. Now we
can just simply update the operand.
Related to <rdar://problem/16381500>
llvm-svn: 204433
 | 
| | 
| 
| 
|  | 
llvm-svn: 204432
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
keep track of constant candidates.
This simplifies working with the constant candidates and removes the tight
coupling between the map and the vector.
Related to <rdar://problem/16381500>
llvm-svn: 204431
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Add an assertion that the section is not NULL.  Potential NULL pointer
dereference identified by clang static analyzer.
llvm-svn: 204429
 | 
| | 
| 
| 
| 
| 
|  | 
The commit r203762 introduced silent failure for complext SO expression, and it's even worse than compiler crash.
llvm-svn: 204427
 | 
| | 
| 
| 
|  | 
llvm-svn: 204426
 | 
| | 
| 
| 
|  | 
llvm-svn: 204425
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
.data_region is only used in Darwin, so it shouldn't be generated
for other OS. Currently AArch64 doesn't support darwin yet, so
I removed it from AArch64. When Darwin is supported someday, we can
add it back and associate it with Darwin.
llvm-svn: 204424
 | 
| | 
| 
| 
| 
| 
|  | 
LockFileManager can handle a symbolic link that points nowhere.
llvm-svn: 204422
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
NumberOfRelocations field in COFF section table is only 16-bit wide. If an
object has more than 65535 relocations, the number of relocations is stored
to VirtualAddress field in the first relocation field, and a special flag
(IMAGE_SCN_LNK_NRELOC_OVFL) is set to Characteristics field.
In test we cheated a bit. I made up a test file so that it has
IMAGE_SCN_LNK_NRELOC_OVFL flag but the number of relocations is much smaller
than 65535. This is to avoid checking in a large test file just to test a
file with many relocations.
Differential Revision: http://llvm-reviews.chandlerc.com/D3139
llvm-svn: 204418
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Sicne MBB->computeRegisterLivenes() returns Dead for sub regs like s0,
d0 is used in vpop instead of updating sp, which causes s0 dead before
its use.
This patch checks the liveness of each subreg to make sure the reg is
actually dead.
llvm-svn: 204411
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The function exists to force an expression to be absolute, but there it is not
possible to force a symbol reference since
a = b
.long a
means something else.
This is an alternative fix for pr9951 that uses an assert. It then deletes
the old pr9951 test that was testing nothing already.
llvm-svn: 204399
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
RTDyldMemoryManager, regardless of whether it thinks they're "required for
execution".
Currently, RuntimeDyld only passes sections that are "required for execution"
to the RTDyldMemoryManager, and takes "required for execution" to mean exactly
"contains symbols or relocations". There are two problems with this:
(1) It can drop sections with anonymous data that is referenced by code.
(2) It leaves the JIT client no way to inspect interesting sections that aren't
    actually required to run the program (e.g dwarf sections).
A test case is still in the works.
Future work: We may want to replace this with a generic section filtering
mechanism, but that will require more consideration. For now, this flag at least
allows clients to volunteer to do the filtering themselves.
Fixes <rdar://problem/15177691>.
llvm-svn: 204398
 | 
| | 
| 
| 
| 
| 
|  | 
I will break this up into smaller pieces for review and recommit.
llvm-svn: 204393
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
This commit extends the coverage of the constant hoisting pass, adds additonal
debug output and updates the function names according to the style guide.
Related to <rdar://problem/16381500>
llvm-svn: 204389
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This option caused LowerInvoke to generate code using SJLJ-based
exception handling, but there is no code left that interprets the
jmp_buf stack that the resulting code maintained (llvm.sjljeh.jblist).
This option has been obsolete for a while, and replaced by
SjLjEHPrepare.
This leaves the default behaviour of LowerInvoke, which is to convert
invokes to calls.
Differential Revision: http://llvm-reviews.chandlerc.com/D3136
llvm-svn: 204388
 | 
| | 
| 
| 
|  | 
llvm-svn: 204378
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Use the range machinery for DW_AT_ranges and DW_AT_high/lo_pc.
    This commit moves us from a single range per subprogram to extending
    ranges if we are:
    a) In the same section, and
    b) In the same enclosing CU.
    This means we have more fine grained ranges for compile units, and fewer
    ranges overall when we have multiple functions in the same CU
    adjacent to each other in the object file.
    Also remove all of the earlier hacks around this functionality for
    function sections etc. Also update all of the testcases to take into
    account the merging functionality.
with a fix for location entries in the debug_loc section:
Make sure that debug loc entries are relative to the low_pc
of the compile unit. This means that when we only have a single
range that the offset should be just relative to the low_pc
of the unit, for multiple ranges for a CU this means that we'll be
relative to 0 which we emit along with DW_AT_ranges.
This mostly shows up with linked binaries, so add a testcase with
multiple CUs so that our location is going to be offset of a CU
with a non-zero low_pc.
llvm-svn: 204377
 | 
| | 
| 
| 
| 
| 
|  | 
is_symlink was always false since it was using stat instead of lstat.
llvm-svn: 204361
 | 
| | 
| 
| 
|  | 
llvm-svn: 204358
 | 
| | 
| 
| 
|  | 
llvm-svn: 204357
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The Octeon cpu from Cavium Networks is mips64r2 based and has an extended
instruction set. In order to utilize this with LLVM, a new cpu feature "octeon"
and a subtarget feature "cnmips" is added. A small set of new instructions
(baddu, dmul, pop, dpop, seq, sne) is also added. LLVM generates dmul, pop and
dpop instructions with option -mcpu=octeon or -mattr=+cnmips.
llvm-svn: 204337
 | 
| | 
| 
| 
| 
| 
|  | 
Fixes https://code.google.com/p/address-sanitizer/issues/detail?id=279.
llvm-svn: 204331
 | 
| | 
| 
| 
|  | 
llvm-svn: 204329
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: http://llvm-reviews.chandlerc.com/D3112
llvm-svn: 204325
 | 
| | 
| 
| 
| 
| 
|  | 
http://llvm-reviews.chandlerc.com/D3080
llvm-svn: 204323
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Also removed some unnecessary #includes.
No functional changes.
llvm-svn: 204320
 | 
| | 
| 
| 
|  | 
llvm-svn: 204318
 | 
| | 
| 
| 
| 
| 
| 
|  | 
We would emit a pair of double quotes inside a pair of single quotes.
Just use a pair of single quotes.
llvm-svn: 204312
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Re-apply the change after it was reverted to do conflicts due to another change
being reverted.
llvm-svn: 204306
 | 
| | 
| 
| 
| 
| 
|  | 
particular this makes a too short instruction with a missing SIB byte fail.
llvm-svn: 204305
 | 
| | 
| 
| 
| 
| 
|  | 
treating DPair as QPR.
llvm-svn: 204304
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Given
bar = foo + 4
	.long bar
MC would eat the 4. GNU as includes it in the relocation. The rule seems to be
that a variable that defines a symbol is used in the relocation and one that
does not define a symbol is evaluated and the result included in the relocation.
Fixing this unfortunately required some other changes:
* Since the variable is now evaluated, it would prevent the ELF writer from
  noticing the weakref marker the elf streamer uses. This patch then replaces
  that with a VariantKind in MCSymbolRefExpr.
* Using VariantKind then requires us to look past other VariantKind to see
	.weakref	bar,foo
	call	bar@PLT
  doing this also fixes
	zed = foo +2
	call zed@PLT
  so that is a good thing.
* Looking past VariantKind means that the relocation selection has to use
  the fixup instead of the target.
This is a reboot of the previous fixes for MC. I will watch the sanitizer
buildbot and wait for a build before adding back the previous fixes.
llvm-svn: 204294
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This appears to trigger failures with optimization and function arguments somehow.
This reverts commit r204277.
llvm-svn: 204286
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This commit moves us from a single range per subprogram to extending
ranges if we are:
a) In the same section, and
b) In the same enclosing CU.
This means we have more fine grained ranges for compile units, and fewer
ranges overall when we have multiple functions in the same CU
adjacent to each other in the object file.
Also remove all of the earlier hacks around this functionality for
function sections etc. Also update all of the testcases to take into
account the merging functionality.
llvm-svn: 204277
 | 
| | 
| 
| 
|  | 
llvm-svn: 204275
 | 
| | 
| 
| 
|  | 
llvm-svn: 204274
 | 
| | 
| 
| 
| 
| 
| 
|  | 
v2:
  -Use correct opcode for DS_READ_64
llvm-svn: 204273
 | 
| | 
| 
| 
|  | 
llvm-svn: 204272
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
It isn't actually used now, and probably never will be, plus it makes
tests less annoying. I also think SC prints GDS instructions as a
separate instruction name.
llvm-svn: 204270
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Also remove unused data fields from the DS_Load_Helper class.
v2:
  - Merge fields for DS_WRITE
llvm-svn: 204269
 | 
| | 
| 
| 
|  | 
llvm-svn: 204256
 | 
| | 
| 
| 
|  | 
llvm-svn: 204252
 | 
| | 
| 
| 
|  | 
llvm-svn: 204230
 | 
| | 
| 
| 
|  | 
llvm-svn: 204216
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The current state of affairs has auxiliary symbols described as a big
bag of bytes. This is less than satisfying, it detracts from the YAML
file as being human readable.
Instead, allow for symbols to optionally contain their auxiliary data.
This allows us to have a much higher level way of describing things like
weak symbols, function definitions and section definitions.
This depends on D3105.
Differential Revision: http://llvm-reviews.chandlerc.com/D3092
llvm-svn: 204214
 |