You can override the value of these during CMake, and we often use sentinels
with more than one digit (not to mention our actual Clang being 700.whatever).

llvm-svn: 260596

Use x29 and x30 for fp and lr respectively.

This does not change the code generation with integrated asm
but using x30 and x29 helps compile the code with gnu as. Currently gas
fails to assemble this code with errors as below.

Error: operand X should be an integer register.

Newer versions of binutils should be fixed, but enough exists in the wild
to make this change harmless and worthy.

Patch by Khem Raj.

llvm-svn: 260595

llvm-svn: 260594

llvm-svn: 260593

Previously, Target held a value until a new value is assigned to the
variable. That was a benign leak -- that was not an unbounded leak
and didn't grab any resources except a small amount of memory. But
it is better to fix than leaving as is.

llvm-svn: 260592

Previously, we had code for linker scripts in Writer. This patch
separates that as LinkerScript class. The class provides a few
functions to query linker scripts and is also a container of some
linker-script-specific information.

Hopefully, Writer will only implement the default behavior and let
the new class handle gotchas regarding linker scripts.

llvm-svn: 260591

llvm-svn: 260590

llvm-svn: 260589

Summary:
When we split SMRD instructions into two MUBUFs we were adding the users
of the newly created MUBUFs to the VALU worklist.  However, the only
users these instructions had was the REG_SEQUENCE that was inserted
by splitSMRD when the original SMRD instruction was split.

We need to make sure to add the users of the original SMRD to the VALU
worklist before it is split.

I have a test case, but it requires one other bug fix, so it will be
added in a later commt.

Reviewers: mareko, arsenm

Subscribers: arsenm, llvm-commits

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

llvm-svn: 260588

When optimizing a extractvalue(load), we generate a load from the
aggregate type.  This load didn't have alignment set and so would
get the alignment of the type.  This breaks when the type is packed
and so the alignment should be lower.

For example, loading { int, int } would give us alignment of 4, but
the original load from this type may have an alignment of 1 if packed.

Reviewed by David Majnemer

Differential revision: http://reviews.llvm.org/D17158

llvm-svn: 260587

This is broke a bot:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/4703/steps/test-suite/logs/test.log

Reverting while I investigate.

This reverts commit r260565.

llvm-svn: 260586

Reviewers: sunfish, jfb

Subscribers: jfb, dschuff

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

llvm-svn: 260585

XFAIL this test for PPC64 for now. It looks like the *_MIN_EXP macros are in fact defined incorrectly for that target.

llvm-svn: 260583

The code change is simple enough: instead of attaching an anonymous SDLoc to splatted
vector constants, use the scalar constant's existing SDLoc since that is what is passed 
into getConstant() as a param. But this changes instruction scheduling, so I'll explain
why that happens.

The motivation for this patch starts near:
http://reviews.llvm.org/rL258833
...x86's getZeroVector() could be similarly cleaned up and I thought it would be 'NFC'.
But when I made that change locally, several x86 codegen tests wiggled.

It turns out that the lack of SDLoc consistency in getConstant() changes the way 
ScheduleDAGRRList behaves. This is because the SDLoc contains 'IROrder' and some DAG
scheduler algorithms use IROrder for tie-breaking.

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

llvm-svn: 260582

llvm-svn: 260581

llvm-svn: 260579

Rather than storing type units in a vector and emitting them at the end
of code generation, emit them immediately and destroy them, reclaiming the
memory we were using for their DIEs.

In one benchmark carried out against Chromium's 50 largest (by bitcode
file size) translation units, total peak memory consumption with type units
decreased by median 17%, or by 7% when compared against disabling type units.

Tested using check-{llvm,clang}, the GDB 7.5 test suite (with
'-fdebug-types-section') and by eyeballing llvm-dwarfdump output on those
Chromium translation units with split DWARF both disabled and enabled, and
verifying that the only changes were to addresses and abbreviation ordering.

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

llvm-svn: 260578

Patch by Jorge Teixeira!

llvm-svn: 260577

We can do it since getMemBuffer returns a unique_ptr.

llvm-svn: 260576

llvm-svn: 260574

llvm-svn: 260573

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

llvm-svn: 260572

If there were wrapper functions with no instructions of their own in the
inlining tree, we would fail to emit InlineSite records for them.

llvm-svn: 260571

prototypes for <string.h> functions that are converted into overload sets in
C++. This matches the existing workaround in <wchar.h>.

llvm-svn: 260570

llvm-svn: 260569

llvm-svn: 260568

This commit changes the root from "Simple C/C++ TBAA" to "Simple C++ TBAA" for
C++.

The problem is that the type name in the TBAA nodes is generated differently
for C vs C++. If we link an IR file for C with an IR file for C++, since they
have the same root and the type names are different, accesses to the two type
nodes will be considered no-alias, even though the two type nodes are from
the same type in a header file.

The fix is to use different roots for C and C++. Types from C will be treated
conservatively in respect to types from C++.

Follow-up commits will change the C root to "Simple C TBAA" plus some mangling
change for C types to make it a little more aggresive.

llvm-svn: 260567

The rational for this change is that LLVMBuild cannot express conditional 
dependencies. Therefore, when we start optionally using GlobalISel library for 
say AArch64, without that change, all the tools that use the AArch64 library 
would need to explicitly link with GlobalISel when we ask for it.

This does not scale.

Instead, we will set the dependencies between the target and GlobalISel and if 
we did not ask to build GlobalISel, the library will just be empty.

Thanks to Chris Bieneman and Mehdi Animi for the idea.

llvm-svn: 260566

If two definitions write to independent subregisters then they can be
put in any order. LiveIntervalAnalysis::handleMove() did not support
this previously because it looks like moving a definition of a vreg past
another one.

This is a modified version of a patch proposed (two years ago) by
Vincent Lejeune! This version does not touch the read-undef flags and is
extended for the case of moving a subregister def behind all uses - this
can happen for subregister defs that are completely unused.

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

llvm-svn: 260565

llvm-svn: 260564

If we didn't tell ReadOptionsBlock to allow failures then we can't
assume that the stream is not in the middle of a block if it returns
out-of-date. This was causing a crash when we tried to continue reading.

Also, it's just generally a good idea to early-exit if we're doing
implicit module builds, since we will want to immediately rebuild this
module anyway and there's no reason to waste time continuing after
failure.

rdar://problem/24114938

llvm-svn: 260563

llvm-svn: 260562

llvm-svn: 260561

Summary:
Added support for "VOP3Only" attribute in VOP3bInst encoding.
Set VOP3Only=1 for V_DIV_SCALE_F64/32 insns.
Added support for multi-dest instructions in AMDGPUAs::cvt*().
Added lit test for "V_DIV_SCALE_F64|F32 vreg,vcc|sreg,vreg,vreg,vreg".

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm, SamWot, nhaustov, vpykhtin

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

Patch By: Artem Tamazov

llvm-svn: 260560

In some circumstances (notably, certain minidumps), the thread CONTEXT does not have values for the
control registers (EIP, ESP, EBP, EFLAGS).  There are flags in the CONTEXT which indicate which
portions are valid, but those flags weren't checked.  The old code would not detect this and give a
garbage value for the register.  The new code will log the problem and return an error.

I consolidated the error checking and logging into a helper function, which makes the big switch
statement easier to read and verify.

Ran tests to ensure this doesn't break anything.  Manually verified that a minidump without info on
the control registers now indicates the problem instead of giving bad information.

Differential Review: http://reviews.llvm.org/D17152

llvm-svn: 260559

We actually need that information only for generic instructions, therefore it
would be nice not to have to pay the extra memory consumption for all
instructions. Especially because a typed non-generic instruction does not make
sense.

The question is then, is it possible to have that information in a union or
something?
My initial thought was that we could have a derived class GenericMachineInstr
with additional information, but in practice it makes little to no sense since
generic MachineInstrs are likely turned into non-generic ones by just switching
the opcode. In other words, we don't want to go through the process of creating
a new, non-generic MachineInstr, object each time we do this switch. The memory
benefit probably is not worth the extra compile time.

Another option would be to keep the type of the MachineInstr in a side table.
This would induce an extra indirection though.

Anyway, I will file a PR to discuss about it and remember we need to come back
to it at some point.

llvm-svn: 260558

.. so .loc directives referring to those files work correctly.

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

llvm-svn: 260557

llvm-svn: 260556

http://reviews.llvm.org/D17124

llvm-svn: 260555

Summary:
In some cases stack pointer register (SP) doesn't point into the thread
stack: e.g. if one is using swapcontext(). In this case LSan
conservatively tries to scan the whole thread stack for pointers.
However, thread stack (at least in glibc implementation) may also
include guard pages, causing LSan to crash when it's reading from them.

One of the solutions is to use a pthread_attr_getguardsize() to adjust
the calculated stack boundaries. However, here we're just using
IsAccessibleMemoryRange to skip guard pages and make the code (slightly)
less platform-specific.

Reviewers: kcc

Subscribers: llvm-commits

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

llvm-svn: 260554