Revert r163878 as it breaks on targets with alternate register names. Such targets do not exist in the main tree so this was not noticed.

llvm-svn: 163959

Patch by Reed Kotler.

llvm-svn: 163956

destination.

Updated previous implementation to fix a case not covered:
// PBI: br i1 %x, TrueDest, BB
// BI:  br i1 %y, TrueDest, FalseDest
The other case was handled correctly.
// PBI: br i1 %x, BB, FalseDest
// BI:  br i1 %y, TrueDest, FalseDest

Also tried to use 64-bit arithmetic instead of APInt with scale to simplify the
computation. Let me know if you have other opinions about this.

llvm-svn: 163954

Collect processor resources from the subtarget defs.

llvm-svn: 163953

Infer SchedClasses from variants defined by the target or subtarget.

llvm-svn: 163952

Collect SchedClasses and SchedRW types from the subtarget defs.

llvm-svn: 163951

llvm-svn: 163950

 - The current_pos function is supposed to return all the written bytes, not the
   current position of the underlying stream.
 - This caused tell() to be broken whenever the underlying stream had buffered
   content.

llvm-svn: 163948

llvm-svn: 163947

llvm-svn: 163945

Review by Chandler Carruth.

llvm-svn: 163944

case to a conditional branch and when removing dead cases.

llvm-svn: 163942

llvm-svn: 163940

llvm-svn: 163935

llvm-svn: 163934

llvm-svn: 163933

llvm-svn: 163932

lit config.

llvm-svn: 163928

llvm-svn: 163926

llvm-svn: 163922

This models the A9 processor at the level of instruction operands, as
opposed to the itinerary, which models each operation at the level of
pipeline stages.

The two primary motivations are:

1) Allow MachineScheduler to model A9 as an out-of-order processor. It
can now distinguish between hazards that force interlocking vs.
buffered resources.

2) Reduce long-term maintenance by allowing the itinerary and target
hooks to eventually be removed. Note that almost all of the complexity
in the new model exists to model instruction variants, which the
itinerary cannot handle. Instead the scheduler previously relied on
processor-specific target hooks which are incomplete and buggy.

llvm-svn: 163921

the default target of the first switch is not the basic block the second switch
is in (PredDefault != BB).

llvm-svn: 163916

llvm-svn: 163915

llvm-svn: 163904

This patch introduces a possibility for Hexagon MI scheduler
to perform some target specific post- processing on the scheduling
DAG prior to scheduling.

llvm-svn: 163903

* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
  people want -- it starts a new paragraph);
* use \param instead of \arg to document parameters in order to be consistent
  with the rest of the codebase.

llvm-svn: 163902

The NDEBUG hack is ugly, but I see no better solution.

llvm-svn: 163900

clang warned about this being unused in Release builds.

llvm-svn: 163899

pointless checks in here, bad asserts, and just confusing code. I've
also added a bit more to the comment to clarify what this function is
really trying to do as it was not obvious to Duncan when studying it.

Thanks to Duncan for helping me dig through the issue.

No real functionality changed here in practical cases, and certainly no
test case. This is just cleanup spotted by inspection.

llvm-svn: 163897

explicit check before recursing. A simplification requested by Duncan
during review.

llvm-svn: 163896

inspection by Duncan during review. My suspicion is that we would still
have returned 0 anyways in this case, but doing it sooner is better.

llvm-svn: 163895

deeply suspicious and likely to go away eventually. Also fix a bogus
comment about one of the checks in the vector GEP analysis. Based on
review from Duncan.

llvm-svn: 163894

Originally I had anticipated needing to thread this through more bits of
the SROA pass itself, but that ended up not happening. In the end, this
is a much simpler way to manange the variable.

llvm-svn: 163893

forget from Duncan's review as a FIXME.

llvm-svn: 163892

unexpectedly in the future. More fixes from his code review.

llvm-svn: 163891

being busy testing this...

llvm-svn: 163890

llvm-svn: 163889

llvm-svn: 163888

llvm-svn: 163887

llvm-svn: 163886