Summary:
As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS.

The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled.

With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic.

See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html

Reviewers: bogner, silvas, rnk

Subscribers: llvm-commits

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

llvm-svn: 268670

Thanks to David Li for the clarification.

llvm-svn: 268669

We were creating the copy relocations just fine, but then thinking that
the .bss position could be preempted and creating a dynamic relocation
to it, which would crash at runtime since that memory is read only.

llvm-svn: 268668

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

llvm-svn: 268667

Touch Hexagon/CMakeLists.txt to regenerate build files, since r268641 complains of missing HexagonAlias.td on ninja.

FIXME: TableGen.cmake globs *.td(s) with wildcards for deps. It is not good.
llvm-svn: 268666

llvm-svn: 268665

Add a FixItHint for the new diagnostic for a non-class-scope using-declaration that names a class-scope enumerator.

llvm-svn: 268664

llvm-svn: 268663

Given something like:

    ldr r0, .LCPI0_0 (== pc-rel var)
    add r0, pc

    ldr r1, .LCPI0_1 (== pc-rel var)
    add r1, pc

we cannot combine the 2 ldr instructions and litpools because they get added to
a different pc to form the correct address. I think the original logic came
from a time when we fused the LDRpci/PICADD instructions into one
pseudo-instruction so the PC was always immediately at-hand. That's no longer
the case.

Should fix general-dynamic TLS access on Linux, and quite possibly other -fPIC
code that relies on litpools (e.g. v6m and -Oz compilations) though trivial
tweaks of the .ll test didn't provoke anything.

llvm-svn: 268662

The mem(r0) instructions are treated as mem(r0+#0).

llvm-svn: 268661

MemorySanitizer: use-of-uninitialized-value in lib/Bitcode/Writer/BitcodeWriter.cpp:364:70
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12544/steps/check-llvm%20msan/logs/stdio

This reverts commit 0c4a898ea550699d1b2f4fe3767251c8f9a48d52.

llvm-svn: 268660

llvm-svn: 268659

This should fix the assertions in a clang LTO bootstrap we're seeing.

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

llvm-svn: 268657

llvm-svn: 268656

llvm-svn: 268655

llvm-svn: 268654

This change addresses a hang/segfault in TestEvents.py. The threads that
run the listener loops now do an SBListener.Clear() before they wrap up
their work. This prevents the test from trying to clean up the
SBListener too late.

There is a separate issue here which is that we should prevent this
clean-up time lock-up, but that is out of scope for this particular
change. I'd like to get these tests back and running the normal flow
rather than skipping them.

This addresses:
llvm.org/pr25924 (at least, the OS X side, although I suspect this will
also address Linux)

http://reviews.llvm.org/D19983
reviewed by: Jim Ingham

llvm-svn: 268653

load commands.

The existing test case in test/Object/macho-invalid.test for
macho-invalid-too-small-segment-load-command has a cmdsize of 55, while
being too small also it is not a multiple of 4.  So when that check is added
this test case will produce a different error. So I constructed a new test case
that will trigger the intended error.

I also changed the error message to be consistent with the other malformed Mach-O
file error messages which prints the load command index.  I also removed both
object_error::macho_load_segment_too_small and
object_error::macho_load_segment_too_many_sections from Object/Error.h
as they are not needed and can just use object_error::parse_failed and let the
error message string distinguish the specific error.

llvm-svn: 268652

This should have NFC in the context of codegen, but may have positive
implications on compile-time.

llvm-svn: 268651

Summary:
Discovered by Dave Airlie, fixes an assertion in Khronos OpenGL CTS
GL43-CTS.shader_storage_buffer_object.advanced-matrix.

In this particular case, the buffer load intrinsic fed into a uniform
conditional branch, and led the brcond lowering down the wrong path.

Reviewers: tstellarAMD, arsenm

Subscribers: arsenm, llvm-commits

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

llvm-svn: 268650

This allows the combined LTO object to provide a definition with the same
name as a symbol that was internalized without causing a duplicate symbol
error. This normally happens during parallel codegen which externalizes
originally-internal symbols, for example.

In order to make this work, I needed to relax the undefined symbol error to
only report an error for symbols that are used in regular objects.

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

llvm-svn: 268649

Summary:
Now that LLVM is emitting version 2 of the AMD code object, we can
start using lld again for linking instead of our custom tool.

Reviewers: arsenm, kzhuravl

Subscribers: rafael, cfe-commits

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

llvm-svn: 268648

Summary:
Version 2 is now the default.  If you want to emit version 1, use
the amdgcn--amdhsa-amdcov1 triple.

Reviewers: arsenm, kzhuravl

Subscribers: arsenm, llvm-commits

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

llvm-svn: 268647

llvm-svn: 268646

It always returned the same value (true). No functionality change.

llvm-svn: 268645

llvm-svn: 268644

ThinLTO is using the Module Identifier to find the corresponding entry
in the index. However when reproducing part of the flow from temporary
files generated from the linker, you'd like to process a file and
force llvm-lto to use another module identifier than the current
filename. The alternative would be to tweak the index, which would be
more involved.

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

On Darwin the default is to build PIC and link PIE. We shouldn't need to override that in the Apple Clang distributions.

llvm-svn: 268642

llvm-svn: 268641

This change removes the current timers with ones that partition time properly.
The current timers are nested, so that if a new timer, B, starts when the
current timer, A, is already timing, A's time will include B's. To eliminate
this problem, the partitioned timers are designed to stop the current timer (A),
let the new timer run (B), and when the new timer is finished, restart the
previously running timer (A). With this partitioning of time, a threads' timers
all sum up to the OMP_worker_thread_life time and can now easily show the
percentage of time a thread is spending in different parts of the runtime or
user code.

There is also a new state variable associated with each thread which tells where
it is executing a task. This corresponds with the timers: OMP_task_*, e.g., if
time is spent in OMP_task_taskwait, then that thread executed tasks inside a
#pragma omp taskwait construct.

The changes are mostly changing the MACROs to use the new PARITIONED_* macros,
the new partitionedTimers class and its methods, and new state logic.

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

llvm-svn: 268640

This speeds up a link of chromium with -O2 (but no icf,gc) from
1.940664632 to 1.925578119.

llvm-svn: 268639

This was broken in the grand configuration change.  Now
using -# works again.

llvm-svn: 268638

llvm-svn: 268637

llvm-svn: 268636

The instruction A2_tfrpi has a 64-bit operand, while the corresponding
intrinsic takes a 32-bit value. The actual value has only 8 significant
bits, so the difference is only in the type used to represent it.
In order to map the intrinsic to the instruction, the operand needs to
be extended to the correct type.

llvm-svn: 268635

llvm-svn: 268634

Summary:
Some PHIs can have expressions that are not AddRecExprs due to the presence
of sext/zext instructions. In order to prevent the Loop Vectorizer from
bailing out when encountering these PHIs, we now coerce the SCEV
expressions to AddRecExprs using SCEV predicates (when possible).

We only do this when the alternative would be to not vectorize.

Reviewers: mzolotukhin, anemet

Subscribers: mssimpso, sanjoy, mzolotukhin, llvm-commits

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

llvm-svn: 268633

This moves the validation of PHI inductions into a
separate method, making it easier to reuse this
logic.

llvm-svn: 268632

This backend was supposed to generate C++ code which will re-construct
the LLVM IR passed as input. This seems to me to have very marginal
usefulness in the first place.

However, the code has never been updated to use IRBuilder, which makes
its current value negative -- people who look at the output may be
steered to use the *wrong* C++ APIs to construct IR.

Furthermore, it's generated code that doesn't compile since at least
2013.

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

llvm-svn: 268631