Summary:
I don't know why every singled backend had to redeclare its own DataLayout.
There was a virtual getDataLayout() on the common base TargetMachine, the
default implementation returned nullptr. It was not clear from this that
we could assume at call site that a DataLayout will be available with
each Target.

Now getDataLayout() is no longer virtual and return a pointer to the
DataLayout member of the common base TargetMachine. I plan to turn it into
a reference in a future patch.

The only backend that didn't have a DataLayout previsouly was the CPPBackend.
It now initializes the default DataLayout. This commit is NFC for all the
other backends.

Test Plan: clang+llvm ninja check-all

Reviewers: echristo

Subscribers: jfb, jholewinski, llvm-commits

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

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

__builtin_longjmp to Sema as requested by John McCall.

llvm-svn: 231986

llvm-svn: 231985

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

These flags should be replaced with corresponding
-f(no-)sanitize-recover=<list> flags.

llvm-svn: 231983

The PowerPC backend had a number of loads that were marked as canFoldAsLoad
(and I'm partially at fault here for copying around the relevant line of
TableGen definitions without really looking at what it meant). This is not
right; PPC (non-memory) instructions don't support direct memory operands, and
so there is nothing a 'foldable' instruction could be folded into.

Noticed by inspection, no test case.

The one thing we might lose by doing this is ability to fold some loads into
stackmap/patchpoint pseudo-instructions. However, this was untested, and would
not obviously have worked for extending loads, and I'd rather re-add support
for that once it can be tested.

llvm-svn: 231982

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

llvm-svn: 231981

that control, individually, all of the disparate things it was
controlling.

At the same time move a FIXME in the Hexagon port to a new
subtarget function that will enable a user of the machine
scheduler to avoid using the source scheduler for pre-RA-scheduling.
The FIXME would have this removed, but involves either testcase
changes or adding -pre-RA-sched=source to a few testcases.

llvm-svn: 231980

MachineFunction argument so that we can grab subtarget specific
features off of it.

llvm-svn: 231979

llvm-svn: 231978

llvm-svn: 231977

already have a perfectly cromulent test archive in the driver inputs.

llvm-svn: 231976

header.

From Alexander Esilevich.

llvm-svn: 231975

Mach-O info plist section as strings.

llvm-svn: 231974

The canonical LLVM directory arrangement places binaries in the 'utils/'
tree when they are used as part of building the project. For example,
the tblgen binaries are built out of 'utils/' trees.

Tools which are not used by any other part of the build, including
testing utilities, are just in the 'tools' directory. For example, in
Clang we have 'c-index-test' which is exactly the same kind of thing as
'linker-script-test'.

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

llvm-svn: 231973

From Alexander Esilevich.

llvm-svn: 231972

llvm-svn: 231971

time. The target independent code was passing in one all the
time and targets weren't checking validity before using. Update
a few calls to pass in a MachineFunction where necessary.

llvm-svn: 231970

llvm-svn: 231969

the spec required by std::sort and friends.

Ordering things this way also dramatically simplifies the code as
short-circuit ensures we can skip all of the negative tests.

I've left one FIXME where we're establishing a fairly arbitrary
ordering. Previously, the function compared all types as equal except
for the ones it explicitly handled, but it didn't delegate correctly to
the atomflags when doing so, and so it would fail to be a SWO. The two
possible fixes are to stop comparing the atom flags entirely, or to
establish some arbitrary ordering of the types.

Since it was pure luck which ordering of unequal types we ended up with
previously (the caller was std::sort, not std::stable_sort) I chose to
make the ordering explicit and guaranteed. This seems like the best
conservative approach as I suspect we would want to switch to
stable_sort otherwise in order to have deterministic output.

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

llvm-svn: 231968

This reverts commit r231957.

IntervalMap currently doesn't support keys more aligned than host pointers
and I've been using it with uint64_t keys. This asserts on some 32bits
systems.

Revert while I work on an IntervalMap generalization.

llvm-svn: 231967

This was previously initialized by ProcessGDBRemote::Initialize but lldb-server does not contain ProcessGDBRemote anymore so this needs to be initialized directly.

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

llvm-svn: 231966

80bit Intel/PPC long double is excluded due to lacking support
for the abstraction. Consistently provide saturation logic.
Extend to long double on 128bit IEEE extended platforms.

Initial patch with test cases from GuanHong Liu.
Reviewed by Steve Canon.

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

llvm-svn: 231965

In http://reviews.llvm.org/D7880 the initialization for LLGS was separated out so that LLGS could initialize only the components it needs to. This further reduces the set of components initialized for LLGS.

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

llvm-svn: 231964

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

llvm-svn: 231963

llvm-svn: 231962

If a function is going in an unique section (because of -ffunction-sections
for example), putting a jump table in .rodata will keep .rodata alive and
that will keep alive any other function that also has a jump table.

Instead, put the jump table in a unique section that is associated with the
function.

llvm-svn: 231961

Support for the QPX vector instruction set, used on the IBM BG/Q supercomputer,
has recently been added to the LLVM PowerPC backend. This vector instruction
set requires some ABI modifications because the ABI on the BG/Q expects
<4 x double> vectors to be provided with 32-byte stack alignment, and to be
handled as native vector types (similar to how Altivec vectors are handled on
mainline PPC systems). I've named this ABI variant elfv1-qpx, have made this
the default ABI when QPX is supported, and have updated the ABI handling code
to provide QPX vectors with the correct stack alignment and associated
register-assignment logic.

llvm-svn: 231960

The main issue being fixed here is that APCS targets handling a "byval align N"
parameter with N > 4 were miscounting what objects were where on the stack,
leading to FrameLowering setting the frame pointer incorrectly and clobbering
the stack.

But byval handling had grown over many years, and had multiple layers of cruft
trying to compensate for each other and calculate padding correctly. This only
really needs to be done once, in the HandleByVal function. Elsewhere should
just do what it's told by that call.

I also stripped out unnecessary APCS/AAPCS distinctions (now that Clang emits
byvals with the correct C ABI alignment), which simplified HandleByVal.

rdar://20095672

llvm-svn: 231959

No build failure, found by code inspection.

llvm-svn: 231958

Gather the function ranges [low_pc, high_pc) during DIE selection and
store them along with the offset to apply to them to get the linked
addresses.

This is just the data collection part, it comes with no tests. That
information will be used in multiple followup commits to perform the
relocation of line tables and range sections among other things, and
these commits will add tests.

llvm-svn: 231957

llvm-svn: 231956

DW_AT_low_pc on functions is taken care of by the relocation processing, but
DW_AT_high_pc and DW_AT_low_pc on other lexical scopes need special handling.

llvm-svn: 231955

classes.

llvm-svn: 231954

llvm-svn: 231953

This adds support for copy-constructor closures.  These are generated
when the C++ runtime has to call a copy-constructor with a particular
calling convention or with default arguments substituted in to the call.

Because the runtime has no mechanism to call the function with a
different calling convention or know-how to evaluate the default
arguments at run-time, we create a thunk which will do all the
appropriate work and package it in a way the runtime can use.

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

llvm-svn: 231952

we can inspect the subtarget and function when computing values.

llvm-svn: 231951

definition, be sure to update the definition data on all declarations, not just
the canonical one, since the pattern might not be in the list of pending
definitions (if it used to be canonical itself).

One-line fix by me; reduced testcase by Daniel Jasper!

llvm-svn: 231950

http://reviews.llvm.org/D8239

llvm-svn: 231949

This fixes a bug reported here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150309/265341.html

llvm-svn: 231948