This patch is to support --defsym option for ELF file format/GNU-compatible
driver. Currently it takes a symbol name followed by '=' and a number. If such
option is given, the driver sets up an absolute symbol with the specified
address. You can specify multiple --defsym options to define multiple symbols.

GNU LD's --defsym provides many more features. For example, it allows users to
specify another symbol name instead of a number to define a symbol alias, or it
even allows a symbol plus an offset (e.g. --defsym=foo+3) to define symbol-
relative alias. This patch does not support that, but will be supported in
subsequent patches.

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

llvm-svn: 205029

llvm-svn: 205028

llvm-svn: 205027

llvm-svn: 205026

llvm-svn: 205025

-Wselector-type-mismatch default again. After
internal discussions, we think that in most cases
it has helped our developers find hard to detect
undefined behaviors. We are going to provide a syntax
(and fix-it) to suppress the warning in remaining of
false positive cases.

llvm-svn: 205024

-u behaviour is apparently not portable between linkers (see cfe-commits
discussions for r204379 and r205012).  I've moved the logic to IRGen,
where it should have been in the first place.

I don't have a Linux system to test this on, so it's possible this logic
*still* doesn't pull in the instrumented profiling runtime on Linux.

I'm in the process of getting tests going on the compiler-rt side
(llvm-commits "[PATCH] InstrProf: Add initial compiler-rt test").  Once
we have tests for the full flow there, the runtime logic should get a
whole lot less brittle.

<rdar://problem/16458307>

llvm-svn: 205023

This reverts commit r205012.

llvm-svn: 205022

llvm-svn: 205021

Extract element instructions that will be removed when vectorzing lower the
cost.

Patch by Arch D. Robison!

llvm-svn: 205020

Patch by Arch D. Robison!

llvm-svn: 205019

Patch by Arch D. Robison!

llvm-svn: 205018

The non-SJLJ and SJLJ intrinsics are generated by the frontend and
backend respectively.

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

llvm-svn: 205017

I'll implement error handling and a negative test in both llvm-mc and
Clang soon.

llvm-svn: 205016

If --allow-multiple-definition option is given, LLD does not treat duplicate
symbol error as a fatal error. GNU LD supports this option.

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

llvm-svn: 205015

llvm-svn: 205014

llvm-svn: 205013

llvm-svn: 205012

Before:
  #define A      \
    int i;   /*a*/ \
    int jjj; /*b*/

After:
  #define A        \
    int i;   /*a*/ \
    int jjj; /*b*/

llvm-svn: 205011

This reverts commit r204912, and follow-up commit r204948.

This introduced a performance regression, and the fix is not completely
clear yet.

llvm-svn: 205010

This reverts commit r203553, and follow-up commits r203558 and r203574.

I will follow this up on the mailinglist to do it in a way that won't
cause subtle PRE bugs.

llvm-svn: 205009

Reviewed at http://llvm-reviews.chandlerc.com/D3096

llvm-svn: 205008

Reviewed at http://llvm-reviews.chandlerc.com/D3095

llvm-svn: 205007

llvm-svn: 205006

This was causing my llc to go into an infinite loop on
CodeGen/R600/address-space.ll (just triggered recently by some allocator
changes).

llvm-svn: 205005

These interceptors require deep unpoisoning of return values.
While at it, we do the same for all other pw/gr interceptors to
reduce dependency on libc implementation details.

llvm-svn: 205004

These are used in the ARM backends to aid type-checking on patterns involving
intrinsics. By making sure one argument is an extended/truncated version of
another.

However, there's no reason to limit them to just vectors types. For example
AArch64 has the instruction "uqshrn sD, dN, #imm" which would naturally use an
intrinsic taking an i64 and returning an i32.

llvm-svn: 205003

It's hard to write a reliable test for this code because they
work with unpredictable memory locations. But this change should
fix current failures in getpwent() tests on the sanitizer bots.

llvm-svn: 205002

llvm-svn: 205001

llvm-svn: 205000

Based on patch from GuanHong Liu.

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

llvm-svn: 204999

llvm-svn: 204998

We don't want to deviate from clang's standard terminology.

llvm-svn: 204997

bottom of the interface to make it easier to scan and find the public
API.

No functionality changed.

llvm-svn: 204996

out-of-line private static method and into the collection of inline
alignment helpers in MathExtras.h.

llvm-svn: 204995

llvm-svn: 204994

BumpPtrAllocator significantly less strange by making it a simple
function of the number of slabs allocated rather than by making it
a recurrance. I *think* the previous behavior was essentially that the
size of the slabs would be doubled after the first 128 were allocated,
and then doubled again each time 64 more were allocated, but only if
every allocation packed perfectly into the slab size. If not, the wasted
space wouldn't be counted toward increasing the size, but allocations
over the size threshold *would*. And since the allocations over the size
threshold might be much larger than the slab size, this could have
somewhat surprising consequences where we rapidly grow the slab size.

This currently requires adding state to the allocator to track the
number of slabs currently allocated, but that isn't too bad. I'm
planning further changes to the allocator that will make this state fall
out even more naturally.

It still doesn't fully decouple the growth rate from the allocations
which are over the size threshold. That fix is coming later.

This specific fix will allow making the entire thing into a more
stateless device and lifting the parameters into template parameters
rather than runtime parameters.

llvm-svn: 204993

top of the default jit memory manager. This will allow them to be used
as template parameters rather than runtime parameters in a subsequent
commit.

llvm-svn: 204992

llvm-svn: 204991

llvm-svn: 204990