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

r182872 introduced a bug in how the register-coalescer's rematerialization
handled defining a physical register. It relied on the output of the
coalescer's setRegisters method to determine whether the replacement
instruction needed an implicit-def. However, this value isn't necessarily the
same as the CopyMI's actual destination register which is what the rest of the
basic-block expects us to be defining.

The commit changes the rematerializer to use the actual register attached to
CopyMI in its decision.

This will be tested soon by an X86 patch which moves everything to using
MOV32r0 instead of other sizes.

llvm-svn: 182925

llvm-svn: 182903

llvm-svn: 182902

Fixes PR16146: gdb.base__call-ar-st.exp fails after
pre-RA-sched=source fixes.

Patch by Xiaoyi Guo!

This also fixes an unsupported dbg.value test case. Codegen was
previously incorrect but the test was passing by luck.

llvm-svn: 182885

Not only does this break encapsulation, it's gross.

llvm-svn: 182876

This allows rematerialization during register coalescing to handle
more cases involving operations like SUBREG_TO_REG which might need to
be rematerialized using sub-register indices.

For example, code like:
    v1(GPR64):sub_32 = MOVZ something
    v2(GPR64) = COPY v1(GPR64)
should be convertable to:
    v2(GPR64):sub_32 = MOVZ something

but previously we just gave up in places like this

llvm-svn: 182872

Since the testing case uses ref_addr, which requires version 3+ to work,
we will solve the dwarf version issue first.

This patch also causes failures in one of the bots. I will update the patch
accordingly in my next attempt.

rdar://13926659

llvm-svn: 182867

from a different CU.

We used to print out an error message and fail to generate inlined_subroutine.

If we use ref_addr in the generated DWARF, the DWARF version should be 3 or
above.
rdar://13926659

llvm-svn: 182791

llvm-svn: 182779

llvm-svn: 182778

When -ffast-math is in effect (on Linux, at least), clang defines
__FINITE_MATH_ONLY__ > 0 when including <math.h>. This causes the
preprocessor to include <bits/math-finite.h>, which renames the sqrt functions.
For instance, "sqrt" is renamed as "__sqrt_finite". 

This patch adds the 3 new names in such a way that they will be treated
as equivalent to their respective original names.

llvm-svn: 182739

llvm-svn: 182717

Remove the old IR ordering mechanism and switch to new one.  Fix unit
test failures.

llvm-svn: 182704

Change SelectionDAG::getXXXNode() interfaces as well as call sites of
these functions to pass in SDLoc instead of DebugLoc.

llvm-svn: 182703

Use a field in the SelectionDAGNode object to track its IR ordering.
This adds fields and utility classes without changing existing
interfaces or functionality.

llvm-svn: 182701

llvm-svn: 182680

Now that the LiveDebugVariables pass is running *after* register
coalescing, the ConnectedVNInfoEqClasses class needs to deal with
DBG_VALUE instructions.

This only comes up when rematerialization during coalescing causes the
remaining live range of a virtual register to separate into two
connected components.

llvm-svn: 182592

Lets us use a SetVector instead of an explicit set + vector combination.

llvm-svn: 182586

There were bits & pieces of code lying around that may've given the
impression that debug info metadata supported the possibility that a
subprogram's type could be specified by a non-subroutine type describing
the return type of a void function. This support was incomplete &
unnecessary. Asserts & API have been changed to make the desired usage
more clear.

llvm-svn: 182532

llvm-svn: 182531

llvm-svn: 182527

llvm-svn: 182526

llvm-svn: 182495

The intrinsic calls are dropped, but the annotated value is propagated.

Fixes PR 15253

Original patch by Zeng Bin!

llvm-svn: 182387

Fixes PR16083.

llvm-svn: 182357

This is to fix PR15408 where an undefined symbol Lline_table_start1 is used.
Since we do not generate the debug_line section when .loc is used,
Lline_table_start1 is not emitted and we can't refer to it when calculating
at_stmt_list for a compile unit.

llvm-svn: 182344

This resolves the last of the PR14606 failures in the GDB 7.5 test
suite by implementing an optional name field for
DW_TAG_imported_modules/DIImportedEntities and using that to implement
C++ namespace aliases (eg: "namespace X = Y;").

llvm-svn: 182328

The DWARF EH pass doesn't need the TargetMachine, only the TargetLoweringBase like the other EH passes.

llvm-svn: 182321

llvm-svn: 182317

llvm-svn: 182180