Add lto_codegen_set_assembler_path() API which allows the linker to specify the
path to the assembler tool to run.  When assembler is used (instead of compiler)
different command line options are used.
Add LTO_API_VERSION #define so clients (linkers) can conditionalize use of new APIs.

llvm-svn: 72823

llvm-svn: 72821

 - This matches llvm-ld.

It took a bit of archeology to figure out what the right thing to do was
(whether this was intentionally added or intentionally removed). My final
conclusion is that Chris added this intentionally here:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=16913
but the changes weren't propogated to llvm-ld until here:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=34058
which was after lto.cpp had been cloned off (of llvm-ld), here:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=29494

From the commit message, it looks like the motivation for running global opt
again is because we ran it prior to inlining. Based on that I updated the
comment and also only run the pass if we actually ran the inliner.

Chris, please review.

llvm-svn: 72811

DominatorTreeBase::Split.

llvm-svn: 72810

 - I know it sounds crazy, but I think all the pass lists are now coalesced into
   StandardPasses.h.

llvm-svn: 72805

llvm-svn: 72788

clang/llvm-gcc.
 - Implemented as inline functions for linking simplicity.

llvm-svn: 72786

llvm-svn: 72783

pointer, now that ConstantFoldConstantExpression can
accept a null TargetData pointer.

llvm-svn: 72744

TargetData pointer. The only thing it's used for are
calls to ConstantFoldCompareInstOperands and
ConstantFoldInstOperands, which both already accept a
null TargetData pointer. This makes
ConstantFoldConstantExpression easier to use in clients
where TargetData is optional.

llvm-svn: 72741

llvm-svn: 72740

llvm-svn: 72736

llvm-svn: 72731

llvm-svn: 72729

llvm-svn: 72712

ADDC/ADDE use MVT::i1 (later, whatever it gets legalized to)
instead of MVT::Flag.  Remove CARRY_FALSE in favor of 0; adjust
all target-independent code to use this format.

Most targets will still produce a Flag-setting target-dependent
version when selection is done.  X86 is converted to use i32
instead, which means TableGen needs to produce different code
in xxxGenDAGISel.inc.  This keys off the new supportsHasI1 bit
in xxxInstrInfo, currently set only for X86; in principle this
is temporary and should go away when all other targets have
been converted.  All relevant X86 instruction patterns are
modified to represent setting and using EFLAGS explicitly.  The
same can be done on other targets.

The immediate behavior change is that an ADC/ADD pair are no
longer tightly coupled in the X86 scheduler; they can be
separated by instructions that don't clobber the flags (MOV).
I will soon add some peephole optimizations based on using
other instructions that set the flags to feed into ADC.

llvm-svn: 72707

as necessary.

llvm-svn: 72702

llvm-svn: 72666

llvm-svn: 72650

llvm-svn: 72635

JITCodeEmitter and ObjectCodeEmitter. No functional changes yet. Patch by Aaron Gray

llvm-svn: 72631

llvm-svn: 72622

llvm-svn: 72610

added in clang.

llvm-svn: 72606

llvm-svn: 72603

llvm-svn: 72561

Added optimization that narrow load / op / store and the 'op' is a bit twiddling instruction and its second operand is an immediate. If bits that are touched by 'op' can be done with a narrower instruction, reduce the width of the load and store as well. This happens a lot with bitfield manipulation code.
e.g.
orl     $65536, 8(%rax)
=>
orb     $1, 10(%rax)

Since narrowing is not always a win, e.g. i32 -> i16 is a loss on x86, dag combiner consults with the target before performing the optimization.

llvm-svn: 72507

entries as there are basic blocks in the function.  LiveVariables::getVarInfo
creates a VarInfo struct for every register in the function, leading to
quadratic space use.  This patch changes the BitVector to a SparseBitVector,
which doesn't help the worst-case memory use but does reduce the actual use in
very long functions with short-lived variables.

llvm-svn: 72426

llvm-svn: 72423

llvm-svn: 72411

llvm-svn: 72376

in the case where a loop exit value cannot be computed, instead of only in
some cases while using SCEVCouldNotCompute in others. This simplifies
getSCEVAtScope's callers.

llvm-svn: 72375

sending SCEVUnknowns to expandAddToGEP. This avoids the need for
expandAddToGEP to bend the rules and peek into SCEVUnknown
expressions.

Factor out the code for testing whether a SCEV can be factored by
a constant for use in a GEP index. This allows it to handle
SCEVAddRecExprs, by recursing.

As a result, SCEVExpander can now put more things in GEP indices,
so it emits fewer explicit mul instructions.

llvm-svn: 72366

Fix by clearing the rewriter cache before deleting the trivially dead
instructions.
Also make InsertedExpressions use an AssertingVH to catch these
bugs easier.

llvm-svn: 72364

llvm-svn: 72335

and it wasn't generating calls through @PLT for these functions.
hasLocalLinkage() is now false for available_externally,
I attempted to fix the inliner and dce to handle available_externally properly.
It passed make check.

llvm-svn: 72328

will allow simplifying LegalizeDAG to eliminate type legalization.  (I 
have a patch to do that, but it's not quite finished; I'll commit it 
once it's finished and I've fixed any review comments for this patch.)  
See the comment at the beginning of 
lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp for more details on the
motivation for this patch.

llvm-svn: 72325

code in preparation for code generation.  The main thing it does
is handle the case when eh.exception calls (and, in a future
patch, eh.selector calls) are far away from landing pads.  Right
now in practice you only find eh.exception calls close to landing
pads: either in a landing pad (the common case) or in a landing
pad successor, due to loop passes shifting them about.  However
future exception handling improvements will result in calls far
from landing pads:
(1) Inlining of rewinds.  Consider the following case:
In function @f:
...
  invoke @g to label %normal unwind label %unwinds
...
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

In function @g:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  "rethrow exception"

Now inline @g into @f.  Currently this is turned into:
In function @f:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  invoke "rethrow exception" to label %normal unwind label %unwinds
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

However we would like to simplify invoke of "rethrow exception" into
a branch to the %unwinds label.  Then %unwinds is no longer a landing
pad, and the eh.exception call there is then far away from any landing
pads.

(2) Using the unwind instruction for cleanups.
It would be nice to have codegen handle the following case:
  invoke @something to label %continue unwind label %run_cleanups
...
handler:
... perform cleanups ...
  unwind

This requires turning "unwind" into a library call, which
necessarily takes a pointer to the exception as an argument
(this patch also does this unwind lowering).  But that means
you are using eh.exception again far from a landing pad.

(3) Bugpoint simplifications.  When bugpoint is simplifying
exception handling code it often generates eh.exception calls
far from a landing pad, which then causes codegen to assert.
Bugpoint then latches on to this assertion and loses sight
of the original problem.

Note that it is currently rare for this pass to actually do
anything.  And in fact it normally shouldn't do anything at
all given the code coming out of llvm-gcc!  But it does fire
a few times in the testsuite.  As far as I can see this is
almost always due to the LoopStrengthReduce codegen pass
introducing pointless loop preheader blocks which are landing
pads and only contain a branch to another block.  This other
block contains an eh.exception call.  So probably by tweaking
LoopStrengthReduce a bit this can be avoided.

llvm-svn: 72276

DragonFly OS type.

llvm-svn: 72242

llvm-svn: 72231