[Sparc][LEON] Add LEON-specific CASA instruction.

Differental Revision: http://reviews.llvm.org/D20098

llvm-svn: 269644

[Sparc][LEON] Add UMAC and SMAC instruction support for Sparc LEON subtargets

This change adds SMAC (signed multiply-accumulate) and UMAC (unsigned multiply-accumulate) for LEON subtargets of the Sp

[Sparc][LEON] Add UMAC and SMAC instruction support for Sparc LEON subtargets

This change adds SMAC (signed multiply-accumulate) and UMAC (unsigned multiply-accumulate) for LEON subtargets of the Sparc processor.

The new files LeonFeatures.td and leon-instructions.ll will both be expanded in future, so I want to leave them separate as small files for this review, to be expanded in future check-ins.

Note: The functions are provided only for inline-assembly provision. No DAG selection is provided.

Differential Revision: http://reviews.llvm.org/D19911

llvm-svn: 268908

show more ...

[Sparc] Constification of TargetMachine arguments

This patch changes the TargetMachine arguments to be const. This is
required for {D19265}, and was requested to be done in a separate patch.

Patch

[Sparc] Constification of TargetMachine arguments

This patch changes the TargetMachine arguments to be const. This is
required for {D19265}, and was requested to be done in a separate patch.

Patch by Jacob Hansen!

Differential Revision: http://reviews.llvm.org/D19797

llvm-svn: 268389

show more ...

[SPARC] [SSP] Add support for LOAD_STACK_GUARD.

This fixes PR22248 on sparc.

Differential Revision: http://reviews.llvm.org/D19386

llvm-svn: 267545

Update to use new name alignTo().

llvm-svn: 257804

Revert r247692: Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC.

Eric has replied and has demanded the patch be reverted.

llvm-svn: 247702

Re-commit r247683: Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC.

Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's

Re-commit r247683: Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC.

Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).

For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.

This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.

This commit also contains a trivial patch to clang to account for the C++ API
change. Thanks go to Pavel Labath for fixing LLDB for me.

Reviewers: rengolin

Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin

Differential Revision: http://reviews.llvm.org/D10969

llvm-svn: 247692

show more ...

Revert r247684 - Replace Triple with a new TargetTuple ...

LLDB needs to be updated in the same commit.

llvm-svn: 247686

Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC.

Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).

F

Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC.

Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).

For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.

This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.

This commit also contains a trivial patch to clang to account for the C++ API
change.

Reviewers: rengolin

Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin

Differential Revision: http://reviews.llvm.org/D10969

llvm-svn: 247683

show more ...

[SPARC] Switch to the Machine Scheduler.

The (mostly-deprecated) SelectionDAG-based ILPListDAGScheduler scheduler
was making poor scheduling decisions, causing high register pressure and
extraneous

[SPARC] Switch to the Machine Scheduler.

The (mostly-deprecated) SelectionDAG-based ILPListDAGScheduler scheduler
was making poor scheduling decisions, causing high register pressure and
extraneous register spills.

Switching to the newer machine scheduler generates better code -- even
without there being a machine model defined for SPARC yet.

(Actually committing the test changes too, this time, unlike r247315)

llvm-svn: 247343

show more ...

Revert "[SPARC] Switch to the Machine Scheduler."

This reverts commit r247315.

Accidentally omitted test changes; will resubmit full change shortly.

llvm-svn: 247328

[SPARC] Switch to the Machine Scheduler.

The (mostly-deprecated) SelectionDAG-based ILPListDAGScheduler scheduler
was making poor scheduling decisions, causing high register pressure and
extraneous

[SPARC] Switch to the Machine Scheduler.

The (mostly-deprecated) SelectionDAG-based ILPListDAGScheduler scheduler
was making poor scheduling decisions, causing high register pressure and
extraneous register spills.

Switching to the newer machine scheduler generates better code -- even
without there being a machine model defined for SPARC yet.

llvm-svn: 247315

show more ...

[SPARC] Fix stupid oversight in stack realignment support.

If you're going to realign %sp to get object alignment properly (which
the code does), and stack offsets and alignments are calculated goin

[SPARC] Fix stupid oversight in stack realignment support.

If you're going to realign %sp to get object alignment properly (which
the code does), and stack offsets and alignments are calculated going
down from %fp (which they are), then the total stack size had better
be a multiple of the alignment. LLVM did indeed ensure that.

And then, after aligning, the sparc frame code added 96 (for sparcv8)
to the frame size, making any requested alignment of 64-bytes or
higher *guaranteed* to be misaligned. The test case added with r245668
even tests this exact scenario, and asserted the incorrect behavior,
which I somehow failed to notice. D'oh.

This change fixes the frame lowering code to align the stack size
*after* adding the spill area, instead.

Differential Revision: http://reviews.llvm.org/D12349

llvm-svn: 246042

show more ...

Remove getDataLayout() from TargetSelectionDAGInfo (had no users)

Summary:
Remove empty subclass in the process.

This change is part of a series of commits dedicated to have a single
DataLayout dur

Remove getDataLayout() from TargetSelectionDAGInfo (had no users)

Summary:
Remove empty subclass in the process.

This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.

Reviewers: echristo

Subscribers: jholewinski, llvm-commits, rafael, yaron.keren, ted

Differential Revision: http://reviews.llvm.org/D11045

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 241780

show more ...

Replace string GNU Triples with llvm::Triple in MCSubtargetInfo and create*MCSubtargetInfo(). NFC.

Summary:
This continues the patch series to eliminate StringRef forms of GNU triples
from the inter

Replace string GNU Triples with llvm::Triple in MCSubtargetInfo and create*MCSubtargetInfo(). NFC.

Summary:
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.

Reviewers: rafael

Reviewed By: rafael

Subscribers: rafael, ted, jfb, llvm-commits, rengolin, jholewinski

Differential Revision: http://reviews.llvm.org/D10311

llvm-svn: 239467

show more ...

Reuse a bunch of cached subtargets and remove getSubtarget calls
without a Function argument.

llvm-svn: 227644

Move DataLayout back to the TargetMachine from TargetSubtargetInfo
derived classes.

Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine.

Move DataLayout back to the TargetMachine from TargetSubtargetInfo
derived classes.

Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine. This ensures that global
data is going to be layed out and mangled consistently if the subtarget
changes on a per function basis. Prior to this all targets(*) have
had subtarget dependent code moved out and onto the TargetMachine.

*One target hasn't been migrated as part of this change: R600. The
R600 port has, as a subtarget feature, the size of pointers and
this affects global data layout. I've currently hacked in a FIXME
to enable progress, but the port needs to be updated to either pass
the 64-bitness to the TargetMachine, or fix the DataLayout to
avoid subtarget dependent features.

llvm-svn: 227113

show more ...

Move the various Subtarget dependent members down to the subtarget
for the Sparc port. Use the same initializeSubtargetDependencies
function to handle initialization similar to the other ports to
han

Move the various Subtarget dependent members down to the subtarget
for the Sparc port. Use the same initializeSubtargetDependencies
function to handle initialization similar to the other ports to
handle dependencies.

llvm-svn: 211811

show more ...

[cleanup] Lift using directives, DEBUG_TYPE definitions, and even some
system headers above the includes of generated '.inc' files that
actually contain code. In a few targets this was already done p

[cleanup] Lift using directives, DEBUG_TYPE definitions, and even some
system headers above the includes of generated '.inc' files that
actually contain code. In a few targets this was already done pretty
consistently, but it wasn't done *really* consistently anywhere. It is
strictly cleaner IMO and necessary in a bunch of places where the
DEBUG_TYPE is referenced from the generated code. Consistency with the
necessary places trumps. Hopefully the build bots are OK with the
movement of intrin.h...

llvm-svn: 206838

show more ...

[Modules] Make Support/Debug.h modular. This requires it to not change
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO a

[Modules] Make Support/Debug.h modular. This requires it to not change
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.

This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:

- Header files that need to provide a DEBUG_TYPE for some inline code
can do so by defining the macro before their inline code and undef-ing
it afterward so the macro does not escape.

- We no longer have rampant ODR violations due to including headers with
different DEBUG_TYPE definitions. This may be mostly an academic
violation today, but with modules these types of violations are easy
to check for and potentially very relevant.

Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.

The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.

llvm-svn: 206822

show more ...

Clean up the Legal/Expand logic for SPARC popc.

llvm-svn: 200141

Only generate the popc instruction for SPARC CPUs that implement it.

The popc instruction is defined in the SPARCv9 instruction set
architecture, but it was emulated on CPUs older than Niagara 2.

l

Only generate the popc instruction for SPARC CPUs that implement it.

The popc instruction is defined in the SPARCv9 instruction set
architecture, but it was emulated on CPUs older than Niagara 2.

llvm-svn: 200131

show more ...

[Sparc] Add missing processor types: v7 and niagara

llvm-svn: 199024

[Sparc] Add long double (f128) instructions to sparc backend.

llvm-svn: 189198

Sparc: No functionality change. Cleanup whitespaces, comment formatting etc.,

llvm-svn: 183243