llvm-svn: 184045

llvm-svn: 184039

llvm-svn: 184038

Replace the ill-defined MinLatency and ILPWindow properties with
with straightforward buffer sizes:
MCSchedMode::MicroOpBufferSize
MCProcResourceDesc::BufferSize

These can be used to more precisely model instruction execution if desired.

Disabled some misched tests temporarily. They'll be reenabled in a few commits.

llvm-svn: 184032

"Counts" refer to scaled resource counts within a region. CurrMOps is
simply the number of micro-ops to be issue in the current cycle.

llvm-svn: 184031

llvm-svn: 184030

Heuristics compare the critical path in the scheduled code, called
ExpectedLatency, with the latency of instructions remaining to be
scheduled. There are two ways to look at remaining latency:

(1) Dependent latency includes the latency between unscheduled and
scheduled instructions.

(2) Independent latency is simply the height (bottom-up) or depth
(top-down) of instructions currently in the ready Q.

llvm-svn: 184029

llvm-svn: 184028

This doesn't really effect performance due to all the relevant calls being transparent but is clearer. 

llvm-svn: 184027

Debug Info: Don't print the display name and colon prefix for DEBUG_VALUE comments if the display name is empty

llvm-svn: 184026

llvm-svn: 184012

llvm-svn: 184008

When we're rematerializing into a not-quite-right register we already add the
real definition as an imp-def, but we should also be marking the "official"
register as dead, since nothing else is going to use it as a result of this
remat.

Not doing this can affect pressure tracking.

rdar://problem/14158833

llvm-svn: 184002

SelectionDAG: Fix incorrect condition checks in some cases of folding FADD/FMUL combinations; also improve accuracy of comments

llvm-svn: 183993

in functions which call __builtin_unwind_init()

__builtin_unwind_init() is an undocumented gcc intrinsic which has this effect,
and is used in libgcc_eh.

Goes part of the way toward fixing PR8541.

llvm-svn: 183984

llvm-svn: 183960

operator<< so that functions are printed as just their name instead of as their
entire definition, which is excessively verbose in this context.

llvm-svn: 183871

llvm-svn: 183807

to return and this is done all over.

llvm-svn: 183704

llvm-svn: 183703

llvm-svn: 183698

llvm-svn: 183695

llvm-svn: 183623

instantiation issue with non-standard type.

Add a backend option to warn on a given stack size limit.
Option: -mllvm -warn-stack-size=<limit>
Output (if limit is exceeded):
warning: Stack size limit exceeded (<actual size>) in <functionName>.

The longer term plan is to hook that to a clang warning.
PR:4072
<rdar://problem/13987214>.

llvm-svn: 183595

llvm-svn: 183579

Option: -mllvm -warn-stack-size=<limit>
Output (if limit is exceeded):
warning: Stack size limit exceeded (<actual size>) in <functionName>.

The longer term plan is to hook that to a clang warning.
PR:4072
<rdar://problem/13987214>

llvm-svn: 183552

Fix an assertion when the compiler encounters big constants whose bit width is
not a multiple of 64-bits.
Although clang would never generate something like this, the backend should be
able to handle any legal IR.

<rdar://problem/13363576>

llvm-svn: 183544

OpenBSD's stack smashing protection differs slightly from other
platforms:

  1. The smash handler function is "__stack_smash_handler(const char
     *funcname)" instead of "__stack_chk_fail(void)".

  2. There's a hidden "long __guard_local" object that gets linked
     into each executable and DSO.

Patch by Matthew Dempsky.

llvm-svn: 183533

llvm-svn: 183495

llvm-svn: 183454

Seems we emit the parameter ordering number (spuriously named 'arg
number') in the debug info, so there's no need to search through the
variable list to figure out the parameter ordering. This implementation
does 'always' do the work, even in non-optimized debug info (the
previous implementation checked the existence of the 'variables' list on
the subprogram which is only present in optimized builds).

No intended functionality change.

llvm-svn: 183446

Caching it as a pointer allows us to reset it if the TargetMachine object
changes.

llvm-svn: 183361

The TargetLoweringInfo object is owned by the TargetMachine. In the future, the
TargetMachine object may change, which may also change the TargetLoweringInfo
object.

llvm-svn: 183356

llvm-svn: 183346

When a function is inlined we lazily construct the variables
representing the function's parameters. After that, we add any remaining
unused parameters.

If the function doesn't use all the parameters, or uses them out of
order, then the DWARF would produce them in that order, producing a
parameter order that doesn't match the source.

This fix causes us to always keep the arg variables at the start of the
variable list & in the original order from the source.

llvm-svn: 183297

(4.58s vs 3.2s on an oldish Mac Tower). 

  The corresponding src is excerpted bellow. The lopp accounts for about 90% of execution time.
  --------------------
    cat -n test-suite/MultiSource/Benchmarks/Olden/em3d/make_graph.c
     90 
     91         for (k=0; k<j; k++)
     92           if (other_node == cur_node->to_nodes[k]) break;

  The defective layout is sketched bellow, where the two branches need to swap.
  ------------------------------------------------------------------------
      L:
         ...
      if (cond) goto out-of-loop
      goto L

  While this code sequence is defective, I don't understand why it incurs 1/3 of 
execution time. CPU-event-profiling indicates the poor laoyout dose not increase
in br-misprediction; it dosen't increase stall cycle at all, and it dosen't 
prevent the CPU detect the loop (i.e. Loop-Stream-Detector seems to be working fine
as well)... 

   The root cause of the problem is that the layout pass calls AnalyzeBranch() 
with basic-block which is not updated to reflect its current layout.

rdar://13966341

llvm-svn: 183174

Also simplify code a bit while there. No functionality change.

llvm-svn: 183076

llvm-svn: 183057

Account for the cost of scaling factor in Loop Strength Reduce when rating the
formulae. This uses a target hook.

The default implementation of the hook is: if the addressing mode is legal, the
scaling factor is free.

<rdar://problem/13806271>

llvm-svn: 183045

Removes all uses of the variable UsesNewEH. Simply return false in case that no
resume instructions were found.

llvm-svn: 183016