[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret.

Tailcalls are only OK with forwarded sret pointers. With explicit sret,
one approximation is to check that the pointer isn't a

[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret.

Tailcalls are only OK with forwarded sret pointers. With explicit sret,
one approximation is to check that the pointer isn't an Instruction, as
in that case it might point into some local memory (alloca). That's not
OK with tailcalls.

Explicit sret counterpart to r233409.
Differential Revison: http://reviews.llvm.org/D8510

llvm-svn: 233410

show more ...

[CodeGen] Don't attempt a tail-call with implicit sret.

Tailcalls are only OK with forwarded sret pointers. With sret demotion,
they're not, as we'd have a pointer into a soon-to-be-dead stack frame

[CodeGen] Don't attempt a tail-call with implicit sret.

Tailcalls are only OK with forwarded sret pointers. With sret demotion,
they're not, as we'd have a pointer into a soon-to-be-dead stack frame.

Differential Revison: http://reviews.llvm.org/D8510

llvm-svn: 233409

show more ...

WinEH: Create a parent frame alloca for HandlerType xdata tables

We don't have any logic to emit those tables yet, so the SDAG lowering
of this intrinsic is just a stub. We can see the intrinsic in

WinEH: Create a parent frame alloca for HandlerType xdata tables

We don't have any logic to emit those tables yet, so the SDAG lowering
of this intrinsic is just a stub. We can see the intrinsic in the
prepared IR, though.

llvm-svn: 233354

show more ...

WinEH: Create an unwind help alloca for __CxxFrameHandler3 xdata tables

We don't have any logic to emit those tables yet, so the sdag lowering
of this intrinsic is just a stub. We can see the intrin

WinEH: Create an unwind help alloca for __CxxFrameHandler3 xdata tables

We don't have any logic to emit those tables yet, so the sdag lowering
of this intrinsic is just a stub. We can see the intrinsic in the
prepared IR, though.

llvm-svn: 233209

show more ...

SelectionDAGBuilder: Rangeify a loop. NFC.

llvm-svn: 232831

SelectionDAGBuilder::handleJTSwitchCase, simplify loop; NFC

llvm-svn: 232830

Rewrite SelectionDAGBuilder::Clusterify to run in linear time. NFC.

It was previously repeatedly erasing elements from the middle of a vector,
causing O(n^2) worst-case run-time.

llvm-svn: 232789

Switch lowering: extract NextBlock function. NFC.

llvm-svn: 232759

Switch lowering: remove unnecessary ConstantInt casts. NFC.

llvm-svn: 232729

SelectionDAGBuilder: update comment in HandlePHINodesInSuccessorBlocks.

From what I can tell, the code is checking for PHIs that expect any value from
this block, not just constants.

llvm-svn: 2326

SelectionDAGBuilder: update comment in HandlePHINodesInSuccessorBlocks.

From what I can tell, the code is checking for PHIs that expect any value from
this block, not just constants.

llvm-svn: 232697

show more ...

Recommit r232027 with PR22883 fixed: Add infrastructure for support of multiple memory constraints.

The operand flag word for ISD::INLINEASM nodes now contains a 15-bit
memory constraint ID when the

Recommit r232027 with PR22883 fixed: Add infrastructure for support of multiple memory constraints.

The operand flag word for ISD::INLINEASM nodes now contains a 15-bit
memory constraint ID when the operand kind is Kind_Mem. This constraint
ID is a numeric equivalent to the constraint code string and is converted
with a target specific hook in TargetLowering.

This patch maps all memory constraints to InlineAsm::Constraint_m so there
is no functional change at this point. It just proves that using these
previously unused bits in the encoding of the flag word doesn't break
anything.

The next patch will make each target preserve the current mapping of
everything to Constraint_m for itself while changing the target independent
implementation of the hook to return Constraint_Unknown appropriately. Each
target will then be adapted in separate patches to use appropriate
Constraint_* values.

PR22883 was caused the matching operands copying the whole of the operand flags
for the matched operand. This included the constraint id which needed to be
replaced with the operand number. This has been fixed with a conversion
function. Following on from this, matching operands also used the operand
number as the constraint id. This has been fixed by looking up the matched
operand and taking it from there.

llvm-svn: 232165

show more ...

[X86, AVX2] Replace inserti128 and extracti128 intrinsics with generic shuffles

This should complete the job started in r231794 and continued in r232045:
We want to replace as much custom x86 shuffl

[X86, AVX2] Replace inserti128 and extracti128 intrinsics with generic shuffles

This should complete the job started in r231794 and continued in r232045:
We want to replace as much custom x86 shuffling via intrinsics
as possible because pushing the code down the generic shuffle
optimization path allows for better codegen and less complexity
in LLVM.

AVX2 introduced proper integer variants of the hacked integer insert/extract
C intrinsics that were created for this same functionality with AVX1.

This should complete the removal of insert/extract128 intrinsics.

The Clang precursor patch for this change was checked in at r232109.

llvm-svn: 232120

show more ...

Revert "r232027 - Add infrastructure for support of multiple memory constraints"

This (r232027) has caused PR22883; so it seems those bits might be used by
something else after all. Reverting until

Revert "r232027 - Add infrastructure for support of multiple memory constraints"

This (r232027) has caused PR22883; so it seems those bits might be used by
something else after all. Reverting until we can figure out what else to do.

Original commit message:

The operand flag word for ISD::INLINEASM nodes now contains a 15-bit
memory constraint ID when the operand kind is Kind_Mem. This constraint
ID is a numeric equivalent to the constraint code string and is converted
with a target specific hook in TargetLowering.

This patch maps all memory constraints to InlineAsm::Constraint_m so there
is no functional change at this point. It just proves that using these
previously unused bits in the encoding of the flag word doesn't break anything.

The next patch will make each target preserve the current mapping of
everything to Constraint_m for itself while changing the target independent
implementation of the hook to return Constraint_Unknown appropriately. Each
target will then be adapted in separate patches to use appropriate Constraint_*
values.

llvm-svn: 232093

show more ...

[X86, AVX] replace vextractf128 intrinsics with generic shuffles

Now that we've replaced the vinsertf128 intrinsics,
do the same for their extract twins.

This is very much like D8086 (checked in a

[X86, AVX] replace vextractf128 intrinsics with generic shuffles

Now that we've replaced the vinsertf128 intrinsics,
do the same for their extract twins.

This is very much like D8086 (checked in at r231794):
We want to replace as much custom x86 shuffling via intrinsics
as possible because pushing the code down the generic shuffle
optimization path allows for better codegen and less complexity
in LLVM.

This is also the LLVM sibling to the cfe D8275 patch.

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

llvm-svn: 232045

show more ...

Add infrastructure for support of multiple memory constraints.

Summary:
The operand flag word for ISD::INLINEASM nodes now contains a 15-bit
memory constraint ID when the operand kind is Kind_Mem. T

Add infrastructure for support of multiple memory constraints.

Summary:
The operand flag word for ISD::INLINEASM nodes now contains a 15-bit
memory constraint ID when the operand kind is Kind_Mem. This constraint
ID is a numeric equivalent to the constraint code string and is converted
with a target specific hook in TargetLowering.

This patch maps all memory constraints to InlineAsm::Constraint_m so there
is no functional change at this point. It just proves that using these
previously unused bits in the encoding of the flag word doesn't break anything.

The next patch will make each target preserve the current mapping of
everything to Constraint_m for itself while changing the target independent
implementation of the hook to return Constraint_Unknown appropriately. Each
target will then be adapted in separate patches to use appropriate Constraint_*
values.

Reviewers: hfinkel

Reviewed By: hfinkel

Subscribers: hfinkel, jholewinski, llvm-commits

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

llvm-svn: 232027

show more ...

Handle big index in getelementptr instruction

CodeGen incorrectly ignores (assert from APInt) constant index bigger
than 2^64 in getelementptr instruction. This is a test and fix for that.

Patch by

Handle big index in getelementptr instruction

CodeGen incorrectly ignores (assert from APInt) constant index bigger
than 2^64 in getelementptr instruction. This is a test and fix for that.

Patch by Paweł Bylica!

Reviewed By: rnk

Subscribers: majnemer, rnk, mcrosier, resistor, llvm-commits

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

llvm-svn: 231984

show more ...

Teach lowering to correctly handle invoke statepoint and gc results tied to them. Note that we still can not lower gc.relocates for invoke statepoints.
Also it extracts getCopyFromRegs helper functio

Teach lowering to correctly handle invoke statepoint and gc results tied to them. Note that we still can not lower gc.relocates for invoke statepoints.
Also it extracts getCopyFromRegs helper function in SelectionDAGBuilder as we need to be able to customize type of the register exported from basic block during lowering of the gc.result.
(Resubmitting this change after not being able to reproduce buildbot failure)

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

llvm-svn: 231800

show more ...

[X86, AVX] replace vinsertf128 intrinsics with generic shuffles

We want to replace as much custom x86 shuffling via intrinsics
as possible because pushing the code down the generic shuffle
optimizat

[X86, AVX] replace vinsertf128 intrinsics with generic shuffles

We want to replace as much custom x86 shuffling via intrinsics
as possible because pushing the code down the generic shuffle
optimization path allows for better codegen and less complexity
in LLVM.

This is the sibling patch for the Clang half of this change:
http://reviews.llvm.org/D8088

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

llvm-svn: 231794

show more ...

The operand flag word used in ISD::INLINEASM is an i32 not a pointer. NFC.

Summary:
This is part of the work to support memory constraints that behave
differently to 'm'. The subsequent patches will

The operand flag word used in ISD::INLINEASM is an i32 not a pointer. NFC.

Summary:
This is part of the work to support memory constraints that behave
differently to 'm'. The subsequent patches will expand on the existing
encoding (which is a 32-bit int) and as a result in some flag words will no
longer fit into an i16. This problem only affected the MSP430 target which
appears to have 16-bit pointers.

Reviewers: hfinkel

Reviewed By: hfinkel

Subscribers: hfinkel, llvm-commits

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

llvm-svn: 231783

show more ...

DataLayout is mandatory, update the API to reflect it with references.

Summary:
Now that the DataLayout is a mandatory part of the module, let's start
cleaning the codebase. This patch is a first at

DataLayout is mandatory, update the API to reflect it with references.

Summary:
Now that the DataLayout is a mandatory part of the module, let's start
cleaning the codebase. This patch is a first attempt at doing that.

This patch is not exactly NFC as for instance some places were passing
a nullptr instead of the DataLayout, possibly just because there was a
default value on the DataLayout argument to many functions in the API.
Even though it is not purely NFC, there is no change in the
validation.

I turned as many pointer to DataLayout to references, this helped
figuring out all the places where a nullptr could come up.

I had initially a local version of this patch broken into over 30
independant, commits but some later commit were cleaning the API and
touching part of the code modified in the previous commits, so it
seemed cleaner without the intermediate state.

Test Plan:

Reviewers: echristo

Subscribers: llvm-commits

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

show more ...

SelectionDAGBuilder: Merge 3 copies of the limited precision exp2 emission code.

NFC intended.

llvm-svn: 231406

Replace llvm.frameallocate with llvm.frameescape

Turns out it's pretty straightforward and simplifies the implementation.

Reviewers: andrew.w.kaylor

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

Replace llvm.frameallocate with llvm.frameescape

Turns out it's pretty straightforward and simplifies the implementation.

Reviewers: andrew.w.kaylor

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

llvm-svn: 231386

show more ...

Revert change r231366 as it broke clang-native-arm-cortex-a9 Analysis/properties.m test.

llvm-svn: 231374

Teach lowering to correctly handle invoke statepoint and gc results tied to them. Note that we still can not lower gc.relocates for invoke statepoints.
Also it extracts getCopyFromRegs helper functio

Teach lowering to correctly handle invoke statepoint and gc results tied to them. Note that we still can not lower gc.relocates for invoke statepoints.
Also it extracts getCopyFromRegs helper function in SelectionDAGBuilder as we need to be able to customize type of the register exported from basic block during lowering of the gc.result.

llvm-svn: 231366

show more ...

getRegForInlineAsmConstraint wants to use TargetRegisterInfo for
a lookup, pass that in rather than use a naked call to getSubtargetImpl.
This involved passing down and around either a TargetMachine

getRegForInlineAsmConstraint wants to use TargetRegisterInfo for
a lookup, pass that in rather than use a naked call to getSubtargetImpl.
This involved passing down and around either a TargetMachine or
TargetRegisterInfo. Update all callers/definitions around the targets
and SelectionDAG.

llvm-svn: 230699

show more ...