The `llvm.tls_init_funcs' (created by the front-end) holds pointers to the TLS
initialization functions. These need to be placed into the correct section so
that they are run before `main()'.

<rdar://problem/13733006>

llvm-svn: 180737

For regular object files this is only meaningful for common symbols. An object
file format with direct support for atoms should be able to provide alignment
information for all symbols.

This replaces getCommonSymbolAlignment and fixes
test-common-symbols-alignment.ll on darwin. This also includes a fix to
MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common
(already tested by existing mcjit tests now that it is used).

llvm-svn: 180736

llvm-svn: 180735

The EOP bit was not being encoded.

llvm-svn: 180734

The implemented RuntimeDyldImpl interface is public. Everything else is private.
Since these classes are not inherited from (yet), there is no need to have
protected members.

llvm-svn: 180733

This resurrects r179957, but adds code that makes sure we don't touch
atomic/volatile stores:

This transformation will transform a conditional store with a preceeding
uncondtional store to the same location:

 a[i] =
 may-alias with a[i] load
 if (cond)
   a[i] = Y

into an unconditional store.

 a[i] = X
 may-alias with a[i] load
 tmp = cond ? Y : X;
 a[i] = tmp

We assume that on average the cost of a mispredicted branch is going to be
higher than the cost of a second store to the same location, and that the
secondary benefits of creating a bigger basic block for other optimizations to
work on outway the potential case where the branch would be correctly predicted
and the cost of the executing the second store would be noticably reflected in
performance.

hmmer's execution time improves by 30% on an imac12,2 on ref data sets. With
this change we are on par with gcc's performance (gcc also performs this
transformation). There was a 1.2 % performance improvement on a ARM swift chip.
Other tests in the test-suite+external seem to be mostly uninfluenced in my
experiments:
This optimization was triggered on 41 tests such that the executable was
different before/after the patch. Only 1 out of the 40 tests (dealII) was
reproducable below 100% (by about .4%). Given that hmmer benefits so much I
believe this to be a fair trade off.

llvm-svn: 180731

I recently enabled them on 32 and 64 bit darwin, but it looks like 32 bit is
still fairly broken.

llvm-svn: 180730

llvm-svn: 180729

llvm-svn: 180725

No functionality change.

llvm-svn: 180723

This un-reverts r179735 and reverts commit r180574.

This fixes assertion failures for me locally and should fix the failures
on Windows reported widely on llvm-dev.  We should check if the bots
caught this and if so why not.

llvm-svn: 180722

Re-submitting with fix for OCaml dependency problems (removing dependency on SectionMemoryManager when it isn't used).

Patch by Fili Pizlo

llvm-svn: 180720

This gets most of the MCJITs tests passing with MachO.

llvm-svn: 180716

For MachO we need information that is not represented in ObjRelocationInfo.
Instead of copying the bits we think are needed from a relocation_iterator,
just pass the relocation_iterator down to the format specific functions.

No functionality change yet as we still drop the information once
processRelocationRef returns.

llvm-svn: 180711

llvm-svn: 180700

[objc-arc] Apply the RV optimization to retains next to calls in ObjCARCContract instead of ObjCARCOpts.

Turning retains into retainRV calls disrupts the data flow analysis in
ObjCARCOpts. Thus we move it as late as we can by moving it into
ObjCARCContract.

We leave in the conversion from retainRV -> retain in ObjCARCOpt since
it enables the dataflow analysis.

rdar://10813093

llvm-svn: 180698

llvm-svn: 180697

llvm-svn: 180696

llvm-svn: 180694

[objc-arc-annotations] Moved the disabling of call movement to ConnectTDBUTraversals so that I can prevent Changed = true from being set. This prevents an infinite loop.

llvm-svn: 180693

llvm-svn: 180688

delete blank.

llvm-svn: 180687

llvm-svn: 180686

llvm-svn: 180685

llvm-svn: 180684

Handle tied sub-operands in AsmMatcherEmitter

The problem this patch addresses is the handling of register tie
constraints in AsmMatcherEmitter, where one operand is tied to a
sub-operand of another operand.  The typical scenario for this to
happen is the tie between the "write-back" register of a pre-inc
instruction, and the base register sub-operand of the memory address
operand of that instruction.

The current AsmMatcherEmitter code attempts to handle tied
operands by emitting the operand as usual first, and emitting
a CVT_Tied node when handling the second (tied) operand.  However,
this really only works correctly if the tied operand does not
have sub-operands (and isn't a sub-operand itself).  Under those
circumstances, a wrong MC operand list is generated.

In discussions with Jim Grosbach, it turned out that the MC operand
list really ought not to contain tied operands in the first place;
instead, it ought to consist of exactly those operands that are
named in the AsmString.  However, getting there requires significant
rework of (some) targets.

This patch fixes the immediate problem, and at the same time makes
one (small) step in the direction of the long-term solution, by
implementing two changes:

1. Restricts the AsmMatcherEmitter handling of tied operands to
   apply solely to simple operands (not complex operands or
   sub-operand of such).

This means that at least we don't get silently corrupt MC operand
lists as output.  However, if we do have tied sub-operands, they
would now no longer be handled at all, except for:

2. If we have an operand that does not occur in the AsmString,
   and also isn't handled as tied operand, simply emit a dummy
   MC operand (constant 0).

This works as long as target code never attempts to access
MC operands that do no not occur in the AsmString (and are
not tied simple operands), which happens to be the case for
all targets where this situation can occur (ARM and PowerPC).

[ Note that this change means that many of the ARM custom
  converters are now superfluous, since the implement the
  same "hack" now performed already by common code. ]

Longer term, we ought to fix targets to never access *any*
MC operand that does not occur in the AsmString (including
tied simple operands), and then finally completely remove
all such operands from the MC operand list.

Patch approved by Jim Grosbach.

llvm-svn: 180677

When Reassociator optimize "(x | C1)" ^ "(X & C2)", it may swap the two
subexpressions, however, it forgot to swap cached constants (of C1 and C2)
accordingly.

rdar://13739160

llvm-svn: 180676

Patch by Dimitry Andric.

llvm-svn: 180675

The CodeGen aspects of this test are already covered by cfi-frame.ll;
making it an assembly file reduces the risk of incidental changes
affecting the test.

llvm-svn: 180671

Mainly adding paranoid checks for the closing brace of a function to
help with FileCheck error readability. Also some other minor changes.

No actual CHECK changes.

llvm-svn: 180668

Naturally, we should be able to pass in extra instructions, not just
extra blocks.

llvm-svn: 180667

This seems to me an obvious place to allow target passes to annotate
memory operations. There are plenty of bits, and I'm not aware of
another good way for early target passes to propagate hints along to
later passes. Target independent transforms can simply preserve them,
the way they preserve the other flags. Like MachineMemOperands in
general, if the target flags are lost we must still generate correct
code.

This has lots of uses, but I want this flexibility now to make it
easier to work with the new MachineTraceMetrics
analysis. MachineTraceMetrics can gather a lot of information about
instructions based on the surrounding code. This information can be
used to influence postRA machine passes that don't work on SSA form.

llvm-svn: 180666

llvm-svn: 180665

to determine whether or not we're on a darwin platform for debug code
emitting.

Solves the problem of a module with no triple on the command line
and no triple in the module using non-gdb ok features on darwin. Fix
up the member-pointers test to check the correct things for cross
platform (DW_FORM_flag is a good prefix).

Unfortunately no testcase because I have no ideas how to test something
without a triple and without a triple in the module yet check
precisely on two platforms. Ideas welcome.

llvm-svn: 180660

llvm-svn: 180659

This fixes pr15763.
Patch by David Fang.

llvm-svn: 180657

We switch the order of offset and field type to make TBAAStructType node
(name, parent node, offset) similar to scalar TBAA node (name, parent node).
TypeIsImmutable is added to TBAAStructTag node.

llvm-svn: 180654

Clarify documentation and API to make the difference between register and
register-indirect addressed locations more explicit. Put in a comment
to point out that with the current implementation we cannot specify
a register-indirect location with offset 0 (a breg 0 in DWARF).
No functionality change intended.

rdar://problem/13658587

llvm-svn: 180641

TLVs probably won't be as common as the other types of variables. Check for them
last before defaulting to "DATA".

llvm-svn: 180631

Hopefully brings the windows buildbots back to life.

llvm-svn: 180630