SjLj based exception handling unwinding support. This patch is nasty, brutish
and short. Well, it's kinda short. Definitely nasty and brutish.

The front-end generates the register/unregister calls i

SjLj based exception handling unwinding support. This patch is nasty, brutish
and short. Well, it's kinda short. Definitely nasty and brutish.

The front-end generates the register/unregister calls into the SjLj runtime,
call-site indices and landing pad dispatch. The back end fills in the LSDA
with the call-site information provided by the front end. Catch blocks are
not yet implemented.

Built on Darwin and verified no llvm-core "make check" regressions.

llvm-svn: 78625

show more ...

Rename MVT to EVT, in preparation for splitting SimpleValueType out into its own struct type.

llvm-svn: 78610

Major calling convention code refactoring.

Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
prov

Major calling convention code refactoring.

Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
provides three virtual functions for targets to override:
LowerFormalArguments, LowerCall, and LowerRet, which replace the custom
lowering done on the special nodes. They provide the same information, but
in a more immediately usable format.

This also reworks much of the target-independent tail call logic. The
decision of whether or not to perform a tail call is now cleanly split
between target-independent portions, and the target dependent portion
in IsEligibleForTailCallOptimization.

This also synchronizes all in-tree targets, to help enable future
refactoring and feature work.

llvm-svn: 78142

show more ...

I've changed the semantics of MERGE_VALUES a bit. It's now allowed to live until scheduling. It's deleted when the scheduler translate DAG nodes to machine instructions.

This is currently used by X8

I've changed the semantics of MERGE_VALUES a bit. It's now allowed to live until scheduling. It's deleted when the scheduler translate DAG nodes to machine instructions.

This is currently used by X86 to handle atomic_load_add when the output of the node is not used. I believe there is a better solution. But I find MERGE_VALUES useful for selecting multi-output node when the dead output can be selected as a IMPLICIT_DEF.

llvm-svn: 77583

show more ...

Make EXTRACT_VECTOR_ELT a bit more flexible in terms of the returned
value. Adjust other code to deal with that correctly. Make
DAGTypeLegalizer::PromoteIntRes_EXTRACT_VECTOR_ELT take advantage o

Make EXTRACT_VECTOR_ELT a bit more flexible in terms of the returned
value. Adjust other code to deal with that correctly. Make
DAGTypeLegalizer::PromoteIntRes_EXTRACT_VECTOR_ELT take advantage of
this new flexibility to simplify the code and make it deal with unusual
vectors (like <4 x i1>) correctly. Fixes PR3037.

llvm-svn: 75176

show more ...

dag combine sext(setcc) -> vsetcc before legalize. To make this safe,
VSETCC must define all bits, which is different than it was documented
to before. Since all targets that implement VSETCC alrea

dag combine sext(setcc) -> vsetcc before legalize. To make this safe,
VSETCC must define all bits, which is different than it was documented
to before. Since all targets that implement VSETCC already have this
behavior, and we don't optimize based on this, just change the
documentation. We now get nice code for vec_compare.ll

llvm-svn: 74978

show more ...

Add NumFixedArgs attribute to CallSDNode which indicates the number of fixed arguments in a vararg call.

With the SVR4 ABI on PowerPC, vector arguments for vararg calls are passed differently depend

Add NumFixedArgs attribute to CallSDNode which indicates the number of fixed arguments in a vararg call.

With the SVR4 ABI on PowerPC, vector arguments for vararg calls are passed differently depending on whether they are a fixed or a variable argument. Variable vector arguments always go into memory, fixed vector arguments are put
into vector registers. If there are no free vector registers available, fixed vector arguments are put on the stack.

The NumFixedArgs attribute allows to decide for an argument in a vararg call whether it belongs to the fixed or variable portion of the parameter list.

llvm-svn: 74764

show more ...

fix a really subtle bug in the cross section of aliases and TLS:
the SelectionDAG::getGlobalAddress function properly looks through
aliases to determine thread-localness, but then passes the GV* down

fix a really subtle bug in the cross section of aliases and TLS:
the SelectionDAG::getGlobalAddress function properly looks through
aliases to determine thread-localness, but then passes the GV* down
to GlobalAddressSDNode::GlobalAddressSDNode which does not. Instead
of passing down isTarget, just pass down the predetermined node
opcode. This fixes some assertions with out of tree changes I'm
working on.

llvm-svn: 74325

show more ...

add targetflags to jump tables and constant pool entries.

llvm-svn: 74204

allow setting target operand flags on TargetGlobalAddress nodes.

llvm-svn: 74203

start bringing targetoperand flags into isel, first up, ExternalSymbol.

llvm-svn: 74199

mv CodeGen/DebugLoc.h Support/DebugLoc.h

llvm-svn: 73786

Revert 72707 and 72709, for the moment.

llvm-svn: 72712

Make the implicit inputs and outputs of target-independent
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-inde

Make the implicit inputs and outputs of target-independent
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

show more ...

Update comment, replace theoretically impossible check with an assert.

llvm-svn: 70391

Implement review feedback for vector shuffle work.

llvm-svn: 70372

Add a public method called getAddressSpace() to the GlobalAddressSDNode.

llvm-svn: 70366

2nd attempt, fixing SSE4.1 issues and implementing feedback from duncan.

PR2957

ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than t

2nd attempt, fixing SSE4.1 issues and implementing feedback from duncan.

PR2957

ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -1 represents UNDEF.

In addition to eliminating the creation of illegal BUILD_VECTORS just to
represent shuffle masks, we are better about canonicalizing the shuffle mask,
resulting in substantially better code for some classes of shuffles.

llvm-svn: 70225

show more ...

Revert 69952. Causes testsuite failures on linux x86-64.

llvm-svn: 69967

PR2957

ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -

PR2957

ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -1 represents UNDEF.

In addition to eliminating the creation of illegal BUILD_VECTORS just to
represent shuffle masks, we are better about canonicalizing the shuffle mask,
resulting in substantially better code for some classes of shuffles.

A clean up of x86 shuffle code, and some canonicalizing in DAGCombiner is next.

llvm-svn: 69952

show more ...

Revise my previous change 68996 as suggested by Duncan.

llvm-svn: 69607

Don't try to make BUILD_VECTOR operands have the same
type as the vector element type: allow them to be of
a wider integer type than the element type all the way
through the system, and not just as f

Don't try to make BUILD_VECTOR operands have the same
type as the vector element type: allow them to be of
a wider integer type than the element type all the way
through the system, and not just as far as LegalizeDAG.
This should be safe because it used to be this way
(the old type legalizer would produce such nodes), so
backends should be able to handle it. In fact only
targets which have legal vector types with an illegal
promoted element type will ever see this (eg: <4 x i16>
on ppc). This fixes a regression with the new type
legalizer (vec_splat.ll). Also, treat SCALAR_TO_VECTOR
the same as BUILD_VECTOR. After all, it is just a
special case of BUILD_VECTOR.

llvm-svn: 69467

show more ...

Don't use "protected:" in classes that aren't intended to be
subclassed.

llvm-svn: 69129

Change SelectionDAG type legalization to allow BUILD_VECTOR operands to be
promoted to legal types without changing the type of the vector. This is
following a suggestion from Duncan
(http://lists.c

Change SelectionDAG type legalization to allow BUILD_VECTOR operands to be
promoted to legal types without changing the type of the vector. This is
following a suggestion from Duncan
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/019923.html).
The transformation that used to be done during type legalization is now
postponed to DAG legalization. This allows the BUILD_VECTORs to be optimized
and potentially handled specially by target-specific code.

It turns out that this is also consistent with an optimization done by the
DAG combiner: a BUILD_VECTOR and INSERT_VECTOR_ELT may be combined by
replacing one of the BUILD_VECTOR operands with the newly inserted element;
but INSERT_VECTOR_ELT allows its scalar operand to be larger than the
element type, with any extra high bits being implicitly truncated. The
result is a BUILD_VECTOR where one of the operands has a type larger the
the vector element type.

Any code that operates on BUILD_VECTORs may now need to be aware of the
potential type discrepancy between the vector element type and the
BUILD_VECTOR operands. This patch updates all of the places that I could
find to handle that case.

llvm-svn: 68996

show more ...

Change the NumVTs field from short to int, since there's no
real need for it to be short.

llvm-svn: 68742