Add an inalloca flag to allocas

Summary:
The only current use of this flag is to mark the alloca as dynamic, even
if its in the entry block. The stack adjustment for the alloca can
never be folded

Add an inalloca flag to allocas

Summary:
The only current use of this flag is to mark the alloca as dynamic, even
if its in the entry block. The stack adjustment for the alloca can
never be folded into the prologue because the call may clear it and it
has to be allocated at the top of the stack.

Reviewers: majnemer

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2571

llvm-svn: 199525

show more ...

Fix llc to not reuse spill slots in functions that invoke setjmp()

We need to ensure that StackSlotColoring.cpp does not reuse stack
spill slots in functions that call "returns_twice" functions such

Fix llc to not reuse spill slots in functions that invoke setjmp()

We need to ensure that StackSlotColoring.cpp does not reuse stack
spill slots in functions that call "returns_twice" functions such as
setjmp(), otherwise this can lead to miscompiled code, because a stack
slot would be clobbered when it's still live.

This was already handled correctly for functions that call setjmp()
(though this wasn't covered by a test), but not for functions that
invoke setjmp().

We fix this by changing callsFunctionThatReturnsTwice() to check for
invoke instructions.

This fixes PR18244.

llvm-svn: 199180

show more ...

Begin adding docs and IR-level support for the inalloca attribute

The inalloca attribute is designed to support passing C++ objects by
value in the Microsoft C++ ABI. It behaves the same as byval,

Begin adding docs and IR-level support for the inalloca attribute

The inalloca attribute is designed to support passing C++ objects by
value in the Microsoft C++ ABI. It behaves the same as byval, except
that it always implies that the argument is in memory and that the bytes
are never copied. This attribute allows the caller to take the address
of an outgoing argument's memory and execute arbitrary code to store
into it.

This patch adds basic IR support, docs, and verification. It does not
attempt to implement any lowering or fix any possibly broken transforms.

When this patch lands, a complete description of this feature should
appear at http://llvm.org/docs/InAlloca.html .

Differential Revision: http://llvm-reviews.chandlerc.com/D2173

llvm-svn: 197645

show more ...

Enable variable arguments support for intrinsics.

llvm-svn: 193766

Initial support for Neon scalar instructions.

Patch by Ana Pazos.

1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arit

Initial support for Neon scalar instructions.

Patch by Ana Pazos.

1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arithmetic instructions.

llvm-svn: 191263

show more ...

Implement function prefix data as an IR feature.

Previous discussion:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html

Differential Revision: http://llvm-reviews.chandlerc.com/D1191

Implement function prefix data as an IR feature.

Previous discussion:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html

Differential Revision: http://llvm-reviews.chandlerc.com/D1191

llvm-svn: 190773

show more ...

Extend 'readonly' and 'readnone' to work on function arguments as well as
functions. Make the function attributes pass add it to known library functions
and when it can deduce it.

llvm-svn: 185735

Add CodeGen support for functions that always return arguments via a new parameter attribute 'returned', which is taken advantage of in target-independent tail call opportunity detection and in ARM c

Add CodeGen support for functions that always return arguments via a new parameter attribute 'returned', which is taken advantage of in target-independent tail call opportunity detection and in ARM call lowering (when placed on an integral first parameter).

llvm-svn: 179925

show more ...

minor code style cleanup.

llvm-svn: 177576

Cache the result of Function::getIntrinsicID() in a DenseMap attached to the LLVMContext.

This reduces the time actually spent doing string to ID conversion and shows a 10% improvement in compile ti

Cache the result of Function::getIntrinsicID() in a DenseMap attached to the LLVMContext.

This reduces the time actually spent doing string to ID conversion and shows a 10% improvement in compile time for a particularly bad case that involves ARM Neon intrinsics (these have many overloads).

Patch by Jean-Luc Duprat!

llvm-svn: 176365

show more ...

Don't assert on empty attributes.

llvm-svn: 175785

Add and remove the attribute from the correct slot.

The slot that we're adding/removing the attribute from may not be the same as
the attribute coming in. Make sure that they match up before we try

Add and remove the attribute from the correct slot.

The slot that we're adding/removing the attribute from may not be the same as
the attribute coming in. Make sure that they match up before we try to
add/remove them.
PR15313

llvm-svn: 175684

show more ...

Remove the last of uses that use the Attribute object as a collection of attributes.

Collections of attributes are handled via the AttributeSet class now. This
finally frees us up to make significan

Remove the last of uses that use the Attribute object as a collection of attributes.

Collections of attributes are handled via the AttributeSet class now. This
finally frees us up to make significant changes to how attributes are structured.

llvm-svn: 173228

show more ...

Use the AttributeSet when removing multiple attributes. Use Attribute::AttrKind
when removing one attribute. This further encapsulates the use of the attributes.

llvm-svn: 173214

Use the AttributeSet when adding multiple attributes and an Attribute::AttrKind
when adding a single attribute to the function.

llvm-svn: 173210

More encapsulation work.

Use the AttributeSet when we're talking about more than one attribute. Add a
function that adds a single attribute. No functionality change intended.

llvm-svn: 173196

Support for half intrinsics. Pushes MMX into slower encoding path.

llvm-svn: 172159

Actually update the CMake and Makefile builds correctly, and update the
code that includes Intrinsics.gen directly.

This never showed up in my testing because the old Intrinsics.gen was
still kickin

Actually update the CMake and Makefile builds correctly, and update the
code that includes Intrinsics.gen directly.

This never showed up in my testing because the old Intrinsics.gen was
still kicking around in the make build system and was correct there. =[
Thankfully, some of the bots to clean rebuilds and that caught this.

llvm-svn: 171373

show more ...

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

show more ...

Rename VMCore directory to IR.

Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs

Rename VMCore directory to IR.

Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

llvm-svn: 171359

show more ...